Skip to content

Commit ca4da5d

Browse files
Colin Ian KingJames Morris
Colin Ian King
authored and
James Morris
committed
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>
1 parent cbfe8fa commit ca4da5d

File tree

1 file changed

+5
-3
lines changed

1 file changed

+5
-3
lines changed

Diff for: security/keys/keyring.c

+5-3
Original file line numberDiff line numberDiff line change
@@ -1181,9 +1181,11 @@ void __key_link_end(struct key *keyring,
11811181
if (index_key->type == &key_type_keyring)
11821182
up_write(&keyring_serialise_link_sem);
11831183

1184-
if (edit && !edit->dead_leaf) {
1185-
key_payload_reserve(keyring,
1186-
keyring->datalen - KEYQUOTA_LINK_BYTES);
1184+
if (edit) {
1185+
if (!edit->dead_leaf) {
1186+
key_payload_reserve(keyring,
1187+
keyring->datalen - KEYQUOTA_LINK_BYTES);
1188+
}
11871189
assoc_array_cancel_edit(edit);
11881190
}
11891191
up_write(&keyring->sem);

0 commit comments

Comments
 (0)