retire two issues

git-svn-id: svn+ssh://svn.debian.org/svn/kernel-sec@1606 e094ebfe-e918-0410-adfb-c712417f3574

1 files changed, 34 insertions, 0 deletions

diff --git a/retired/CVE-2009-3624 b/retired/CVE-2009-3624
new file mode 100644
index 00000000..a977aeda
--- /dev/null
+++ b/retired/CVE-2009-3624
@@ -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) [21279cfa107af07ef985539ac0de2152b9cba5f5], released (2.6.31.6) [7a99333e851ef087c7cd836950900602f0843c24]
+linux-2.6: released (2.6.31-2)
+2.6.18-etch-security: N/A
+2.6.24-etch-security: N/A
+2.6.26-lenny-security: N/A