We received the following report via vendor-sec.
This issue is not public yet, please keep any information about it inside SUSE.

Date: Wed, 3 Aug 2005 14:01:39 +0100 (BST)
From: Mark J Cox <mjc@redhat.com>
To: vendor-sec@lst.de
Subject: [vendor-sec] [Security] CAN-2005-2099 Destruction of failed keyring oopses (fwd)

---------- Forwarded message ----------
Date: Wed, 03 Aug 2005 13:19:07 +0100
From: David Howells <dhowells@redhat.com>
To: security@kernel.org
Subject: [Security] 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>
---
warthog>diffstat -p1 /tmp/linux-2.6.13-key-keyring-destroy.patch
 security/keys/keyring.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletion(-)

--- linux-2.6.9/security/keys/keyring.c.orig	2005-07-28 
16:32:16.445246716 +0100
+++ linux-2.6.9/security/keys/keyring.c	2005-07-28 16:32:56.000000000 +0100
@@ -201,7 +201,11 @@ static void keyring_destroy(struct key *

 	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);
 	}


_______________________________________________
Security mailing list
Security@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/security
_______________________________________________
Vendor Security mailing list
Vendor Security@lst.de
https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec