From 66db51c9f7b2fe7ebdfa753b2aa9abbb9feddc87 Mon Sep 17 00:00:00 2001 From: Colin Ian King Date: Mon, 27 Jul 2015 15:23:43 +0100 Subject: [PATCH] KEYS: ensure we free the assoc array edit if edit is valid [ Upstream commit HEAD ] commit ca4da5dd1f99fe9c59f1709fb43e818b18ad20e0 upstream. __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 Upstream-Status: Backport Signed-off-by: Colin Ian King Signed-off-by: David Howells Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman (cherry picked from commit c9cd9b18dac801040ada16562dc579d5ac366d75) Signed-off-by: Sasha Levin Signed-off-by: Sona Sarmadi --- security/keys/keyring.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/security/keys/keyring.c b/security/keys/keyring.c index e72548b..d334370 100644 --- a/security/keys/keyring.c +++ b/security/keys/keyring.c @@ -1181,9 +1181,11 @@ void __key_link_end(struct key *keyring, if (index_key->type == &key_type_keyring) up_write(&keyring_serialise_link_sem); - if (edit && !edit->dead_leaf) { - key_payload_reserve(keyring, - keyring->datalen - KEYQUOTA_LINK_BYTES); + if (edit) { + if (!edit->dead_leaf) { + key_payload_reserve(keyring, + keyring->datalen - KEYQUOTA_LINK_BYTES); + } assoc_array_cancel_edit(edit); } up_write(&keyring->sem); -- 1.9.1