summaryrefslogtreecommitdiffstats
path: root/security/keys/gc.c
diff options
context:
space:
mode:
authorEric Biggers <ebiggers@google.com>2017-06-08 14:49:26 +0100
committerJames Morris <james.l.morris@oracle.com>2017-06-09 13:29:48 +1000
commit0620fddb56dfaf0e1034eeb69d79c73b361debbf (patch)
treee946b82852f2e72c559a1acaa458e7d6e0173acc /security/keys/gc.c
parentee618b4619b72527aaed765f0f0b74072b281159 (diff)
downloadlinux-stable-0620fddb56dfaf0e1034eeb69d79c73b361debbf.tar.gz
linux-stable-0620fddb56dfaf0e1034eeb69d79c73b361debbf.tar.bz2
linux-stable-0620fddb56dfaf0e1034eeb69d79c73b361debbf.zip
KEYS: sanitize key structs before freeing
While a 'struct key' itself normally does not contain sensitive information, Documentation/security/keys.txt actually encourages this: "Having a payload is not required; and the payload can, in fact, just be a value stored in the struct key itself." In case someone has taken this advice, or will take this advice in the future, zero the key structure before freeing it. We might as well, and as a bonus this could make it a bit more difficult for an adversary to determine which keys have recently been in use. This is safe because the key_jar cache does not use a constructor. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: James Morris <james.l.morris@oracle.com>
Diffstat (limited to 'security/keys/gc.c')
-rw-r--r--security/keys/gc.c4
1 files changed, 1 insertions, 3 deletions
diff --git a/security/keys/gc.c b/security/keys/gc.c
index 595becc6d0d2..87cb260e4890 100644
--- a/security/keys/gc.c
+++ b/security/keys/gc.c
@@ -158,9 +158,7 @@ static noinline void key_gc_unused_keys(struct list_head *keys)
kfree(key->description);
-#ifdef KEY_DEBUGGING
- key->magic = KEY_DEBUG_MAGIC_X;
-#endif
+ memzero_explicit(key, sizeof(*key));
kmem_cache_free(key_jar, key);
}
}