summaryrefslogtreecommitdiffstats
path: root/KEYS-close-race-between-key-lookup-and-freeing.patch
diff options
context:
space:
mode:
Diffstat (limited to 'KEYS-close-race-between-key-lookup-and-freeing.patch')
-rw-r--r--KEYS-close-race-between-key-lookup-and-freeing.patch43
1 files changed, 0 insertions, 43 deletions
diff --git a/KEYS-close-race-between-key-lookup-and-freeing.patch b/KEYS-close-race-between-key-lookup-and-freeing.patch
deleted file mode 100644
index 7994e2f3a..000000000
--- a/KEYS-close-race-between-key-lookup-and-freeing.patch
+++ /dev/null
@@ -1,43 +0,0 @@
-From: Sasha Levin <sasha.levin () oracle ! com>
-Date: Mon, 29 Dec 2014 14:39:01 -0500
-Subject: [PATCH] KEYS: close race between key lookup and freeing
-
-When a key is being garbage collected, it's key->user would get put before
-the ->destroy() callback is called, where the key is removed from it's
-respective tracking structures.
-
-This leaves a key hanging in a semi-invalid state which leaves a window open
-for a different task to try an access key->user. An example is
-find_keyring_by_name() which would dereference key->user for a key that is
-in the process of being garbage collected (where key->user was freed but
-->destroy() wasn't called yet - so it's still present in the linked list).
-
-This would cause either a panic, or corrupt memory.
-
-Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
----
- security/keys/gc.c | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/security/keys/gc.c b/security/keys/gc.c
-index 9609a7f0faea..c7952375ac53 100644
---- a/security/keys/gc.c
-+++ b/security/keys/gc.c
-@@ -148,12 +148,12 @@ static noinline void key_gc_unused_keys(struct list_head *keys)
- if (test_bit(KEY_FLAG_INSTANTIATED, &key->flags))
- atomic_dec(&key->user->nikeys);
-
-- key_user_put(key->user);
--
- /* now throw away the key memory */
- if (key->type->destroy)
- key->type->destroy(key);
-
-+ key_user_put(key->user);
-+
- kfree(key->description);
-
- #ifdef KEY_DEBUGGING
---
-2.1.0
-