forked from Minki/linux
a3a8784454
When a key is being garbage collected, it's key->user would get put before the ->destroy() callback is called, where the key is removed from it's respective tracking structures. This leaves a key hanging in a semi-invalid state which leaves a window open for a different task to try an access key->user. An example is find_keyring_by_name() which would dereference key->user for a key that is in the process of being garbage collected (where key->user was freed but ->destroy() wasn't called yet - so it's still present in the linked list). This would cause either a panic, or corrupt memory. Fixes CVE-2014-9529. Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: David Howells <dhowells@redhat.com> |
||
|---|---|---|
| .. | ||
| encrypted-keys | ||
| big_key.c | ||
| compat.c | ||
| gc.c | ||
| internal.h | ||
| Kconfig | ||
| key.c | ||
| keyctl.c | ||
| keyring.c | ||
| Makefile | ||
| permission.c | ||
| persistent.c | ||
| proc.c | ||
| process_keys.c | ||
| request_key_auth.c | ||
| request_key.c | ||
| sysctl.c | ||
| trusted.c | ||
| trusted.h | ||
| user_defined.c | ||