From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Colin Ian King , David Howells , James Morris Subject: [PATCH 3.14 082/125] KEYS: ensure we free the assoc array edit if edit is valid Date: Fri, 31 Jul 2015 12:41:22 -0700 Message-Id: <20150731194030.003242259@linuxfoundation.org> In-Reply-To: <20150731194027.037807932@linuxfoundation.org> References: <20150731194027.037807932@linuxfoundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: 3.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Colin Ian King 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 Signed-off-by: David Howells Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman --- security/keys/keyring.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/security/keys/keyring.c +++ b/security/keys/keyring.c @@ -1151,9 +1151,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);