ca4da5dd1f
__key_link_end is not freeing the associated array edit structure and this leads to a 512 byte memory leak each time an identical existing key is added with add_key(). The reason the add_key() system call returns okay is that key_create_or_update() calls __key_link_begin() before checking to see whether it can update a key directly rather than adding/replacing - which it turns out it can. Thus __key_link() is not called through __key_instantiate_and_link() and __key_link_end() must cancel the edit. CVE-2015-1333 Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: James Morris <james.l.morris@oracle.com> |
||
|---|---|---|
| .. | ||
| encrypted-keys | ||
| Kconfig | ||
| Makefile | ||
| big_key.c | ||
| compat.c | ||
| gc.c | ||
| internal.h | ||
| key.c | ||
| keyctl.c | ||
| keyring.c | ||
| permission.c | ||
| persistent.c | ||
| proc.c | ||
| process_keys.c | ||
| request_key.c | ||
| request_key_auth.c | ||
| sysctl.c | ||
| trusted.c | ||
| trusted.h | ||
| user_defined.c | ||