[kernel-sec-discuss] r1543 - active

Moritz Muehlenhoff jmm at alioth.debian.org
Thu Oct 22 21:56:18 UTC 2009


Author: jmm
Date: 2009-10-22 21:56:17 +0000 (Thu, 22 Oct 2009)
New Revision: 1543

Added:
   active/CVE-2009-3624
Log:
new kernel issue


Added: active/CVE-2009-3624
===================================================================
--- active/CVE-2009-3624	                        (rev 0)
+++ active/CVE-2009-3624	2009-10-22 21:56:17 UTC (rev 1543)
@@ -0,0 +1,34 @@
+Candidate: CVE-2009-3624
+Description:
+ "The destination keyring specified to request_key() and co. is made
+ available to the process that instantiates the key (the slave process
+ started by /sbin/request-key typically).  This is passed in the
+ request_key_auth struct as the dest_keyring member.
+ .
+ keyctl_instantiate_key and keyctl_negate_key() call
+ get_instantiation_keyring() to get the keyring to attach the newly
+ constructed key to at the end of instantiation.  This may be given a
+ specific keyring into which a link will be made later, or it may be
+ asked to find the keyring passed to request_key().  In the former
+ case, it returns a keyring with the refcount incremented by
+ lookup_user_key(); in the latter case, it returns the keyring from the
+ request_key_auth struct - and does _not_ increment the refcount.
+ .
+ The latter case will eventually result in an oops when the keyring
+ prematurely runs out of references and gets destroyed.  The effect may
+ take some time to show up as the key is destroyed lazily. 
+ .
+ To fix this, the keyring returned by get_instantiation_keyring() must
+ always have its refcount incremented, no matter where it comes from."
+References:
+http://git.kernel.org/linus/8bbf4976
+http://git.kernel.org/linus/21279cfa107af07ef985539ac0de2152b9cba5f5
+http://twitter.com/spendergrsec/status/4916661870
+Notes:
+ jmm> Introduced in 2.6.29-rc1
+Bugs:
+upstream: released (2.6.32-rc5)
+linux-2.6: needed
+2.6.18-etch-security: N/A
+2.6.24-etch-security: N/A
+2.6.26-lenny-security: N/A




More information about the kernel-sec-discuss mailing list