oss-security - Re: CVE request: kernel: get_instantiation_keyring() should inc the keyring refcount in all cases

Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu, 22 Oct 2009 15:47:59 -0400 (EDT)
From: Josh Bressers <bressers@...hat.com>
To: oss-security@...ts.openwall.com
Cc: "Steven M. Christey" <coley@...us.mitre.org>
Subject: Re: CVE request: kernel: get_instantiation_keyring()
 should inc the keyring refcount in all cases

Please use CVE-2009-3624 for this.

-- 
    JB


----- "Eugene Teo" <eugeneteo@...nel.sg> wrote:

> Quoting from the upstream commit:
> "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."
> 
> This was introduced in upstream commit 8bbf4976 (v2.6.29-rc1).
> 
> References:
> http://git.kernel.org/linus/8bbf4976
> http://git.kernel.org/linus/21279cfa107af07ef985539ac0de2152b9cba5f5
> http://twitter.com/spendergrsec/status/4916661870
> 
> Thanks, Eugene

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.