lkml.org 
[lkml]   [2005]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[patch 7/8] CAN-2005-2099 Destruction of failed keyring oopses
-stable review patch.  If anyone has any  objections, please let us know.
------------------

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>
---
security/keys/keyring.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletion(-)

Index: linux-2.6.12.y/security/keys/keyring.c
===================================================================
--- linux-2.6.12.y.orig/security/keys/keyring.c
+++ linux-2.6.12.y/security/keys/keyring.c
@@ -188,7 +188,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);
}

--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-08-12 01:00    [W:0.097 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site