Colin Ian King ca4da5dd1f KEYS: ensure we free the assoc array edit if edit is valid ... __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>		2015-07-28 13:08:23 +10:00
..
encrypted-keys
big_key.c
compat.c	switch keyctl_instantiate_key_common() to iov_iter	2015-04-11 22:27:12 -04:00
gc.c
internal.h	switch keyctl_instantiate_key_common() to iov_iter	2015-04-11 22:27:12 -04:00
Kconfig
key.c
keyctl.c	switch keyctl_instantiate_key_common() to iov_iter	2015-04-11 22:27:12 -04:00
keyring.c	KEYS: ensure we free the assoc array edit if edit is valid	2015-07-28 13:08:23 +10:00
Makefile
permission.c
persistent.c
proc.c
process_keys.c
request_key_auth.c
request_key.c	Don't leak a key reference if request_key() tries to use a revoked keyring	2015-02-16 13:45:16 +11:00
sysctl.c
trusted.c
trusted.h
user_defined.c