| From | Greg Kroah-Hartman <> | Subject | [PATCH 4.1 173/267] KEYS: ensure we free the assoc array edit if edit is valid | Date | Fri, 31 Jul 2015 12:40:24 -0700 |
| |
4.1-stable review patch. If anyone has any objections, please let me know.
------------------
From: Colin Ian King <colin.king@canonical.com>
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
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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--- security/keys/keyring.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
--- 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);
|