aboutsummaryrefslogtreecommitdiffstats
path: root/security/keys
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2005-08-04 13:07:07 -0700
committerLinus Torvalds <torvalds@g5.osdl.org>2005-08-04 13:11:14 -0700
commit94efe72f762e2c147d8146d637d5ece5614c8d94 (patch)
tree002e4719541ad838342e01a5f8ff63ae0a618b29 /security/keys
parentbcf945d36fa0598f41ac4ad46a9dc43135460263 (diff)
downloadkernel_samsung_aries-94efe72f762e2c147d8146d637d5ece5614c8d94.zip
kernel_samsung_aries-94efe72f762e2c147d8146d637d5ece5614c8d94.tar.gz
kernel_samsung_aries-94efe72f762e2c147d8146d637d5ece5614c8d94.tar.bz2
[PATCH] Destruction of failed keyring oopses
The attached patch makes sure that a keyring that failed to instantiate properly is destroyed without oopsing [CAN-2005-2099]. The problem occurs in three stages: (1) The key allocator initialises the type-specific data to all zeroes. In the case of a keyring, this will become a link in the keyring name list when the keyring is instantiated. (2) If a user (any user) attempts to add a keyring with anything other than an empty payload, the keyring instantiation function will fail with an error and won't add the keyring to the name list. (3) The keyring's destructor then sees that the keyring has a description (name) and tries to remove the keyring from the name list, which oopses because the link pointers are both zero. This bug permits any user to take down a box trivially. Signed-Off-By: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'security/keys')
-rw-r--r--security/keys/keyring.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/security/keys/keyring.c b/security/keys/keyring.c
index a1f6bac..9c208c7 100644
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -201,7 +201,11 @@ static void keyring_destroy(struct key *keyring)
if (keyring->description) {
write_lock(&keyring_name_lock);
- list_del(&keyring->type_data.link);
+
+ if (keyring->type_data.link.next != NULL &&
+ !list_empty(&keyring->type_data.link))
+ list_del(&keyring->type_data.link);
+
write_unlock(&keyring_name_lock);
}