summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2005-08-03 13:19:07 +0100
committerChris Wright <chrisw@osdl.org>2005-08-14 17:20:10 -0700
commita3692f99ef19cfb7fe0420837852108450dd8124 (patch)
tree6c3550323ee0830339c5c9c67d6b1b1e813fac20
parent1cc2029def8e8b279c050b517a3d635b8a8ad351 (diff)
[PATCH] CAN-2005-2099 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: Chris Wright <chrisw@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-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 e2ab4f8e7481..9c175c599fc7 100644
--- a/security/keys/keyring.c
+++ b/security/keys/keyring.c
@@ -188,7 +188,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);
}