ecryptfs: fix dereference of NULL user_key_payload
authorEric Biggers <ebiggers@google.com>
Mon, 9 Oct 2017 19:51:27 +0000 (12:51 -0700)
committerBen Hutchings <ben@decadent.org.uk>
Mon, 1 Jan 2018 20:50:58 +0000 (20:50 +0000)
commit3feb8b1c61cffa8f9fd22dad04144a0ac954cd85
tree833d159da15a29b575cd520ef9547f9d78036017
parent3b2aa8f209fb50f62935044358651db0ea176c91
ecryptfs: fix dereference of NULL user_key_payload

commit f66665c09ab489a11ca490d6a82df57cfc1bea3e upstream.

In eCryptfs, we failed to verify that the authentication token keys are
not revoked before dereferencing their payloads, which is problematic
because the payload of a revoked key is NULL.  request_key() *does* skip
revoked keys, but there is still a window where the key can be revoked
before we acquire the key semaphore.

Fix it by updating ecryptfs_get_key_payload_data() to return
-EKEYREVOKED if the key payload is NULL.  For completeness we check this
for "encrypted" keys as well as "user" keys, although encrypted keys
cannot be revoked currently.

Alternatively we could use key_validate(), but since we'll also need to
fix ecryptfs_get_key_payload_data() to validate the payload length, it
seems appropriate to just check the payload pointer.

Fixes: 237fead61998 ("[PATCH] ecryptfs: fs/Makefile and fs/Kconfig")
Reviewed-by: James Morris <james.l.morris@oracle.com>
Cc: Michael Halcrow <mhalcrow@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
[bwh: Backported to 3.2: user key payload is key->payload.data, not
 key->payload.data[0]]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
fs/ecryptfs/ecryptfs_kernel.h
fs/ecryptfs/keystore.c