[Lucid][CVE-2015-3339] fs: take i_mutex during prepare_binprm for set[ug]id executables

Luis Henriques luis.henriques at canonical.com
Mon Apr 27 14:10:37 UTC 2015


On Mon, Apr 27, 2015 at 08:46:03AM -0500, Seth Forshee wrote:
> On Mon, Apr 27, 2015 at 01:43:58PM +0100, Luis Henriques wrote:
> > From: Jann Horn <jann at thejh.net>
> > 
> > This prevents a race between chown() and execve(), where chowning a
> > setuid-user binary to root would momentarily make the binary setuid
> > root.
> > 
> > This patch was mostly written by Linus Torvalds.
> > 
> > Signed-off-by: Jann Horn <jann at thejh.net>
> > Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
> > (backported from commit 8b01fc86b9f425899f8a3a8fc1c47d73c2c20543)
> > [ luis: backport to Lucid:
> >   - replaced kuid_t/kgid_t by uid_t/gid_t
> >   - replaced READ_ONCE() by ACCESS_ONCE()
> >   - replaced task_no_new_privs() by current->no_new_privs
> 
> <snip>
> 

Doh!  This is a copy&paste problem -- I should have removed this line
from the Lucid backport.  I'll do that when applying it to Lucid (let
me know if you rather have me resubmitting with this fixed).

> > +static void bprm_fill_uid(struct linux_binprm *bprm)
> > +{
> > +	struct inode *inode;
> > +	unsigned int mode;
> > +	uid_t uid;
> > +	gid_t gid;
> > +
> > +	/* clear any previous set[ug]id data from a previous binary */
> > +	bprm->cred->euid = current_euid();
> > +	bprm->cred->egid = current_egid();
> > +
> > +	if (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)
> > +		return;
> 
> The current->no_new_privs bit is missing here, not sure if it's missing
> or if the commit log is wrong and that part isn't relevant for lucid.
> 

My understanding is that it is not relevant.  If you look at the
backport for Precise, the "current->no_new_privs" was dropped from the
prepare_binprm() and moved into bprm_fill_uid().  Since Lucid doesn't
have this check in prepare_binprm(), I haven't added it into the new
function.  Actually, struct task_struct in Lucid doesn't even have
that field.

Cheers,
--
Luís


> Otherwise the backport looks correct to me.
> 





More information about the kernel-team mailing list