]> git.itanic.dy.fi Git - linux-stable/commit
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:51:53 +0000 (20:51 +0000)
commit09b65e75e671d51dcf8ba4f40a2167cb9afe8afd
treec0edaf7bbc9c59c07a0c1c8aea5acf7d1a44a69f
parent89fd0e583cfaf225075fd6a5c392940f7a71fa73
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.16: 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