Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Mar 2015 21:29:04 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Mateusz Guzik <mjguzik@gmail.com>, jenkins-admin@freebsd.org, freebsd-current@freebsd.org, Mateusz Guzik <mjg@freebsd.org>
Subject:   Re: [PATCH 1/3] fork: assign refed credentials earlier
Message-ID:  <20150321192904.GQ2379@kib.kiev.ua>
In-Reply-To: <20150321181931.GA14650@dft-labs.eu>
References:  <20150320122125.GP2379@kib.kiev.ua> <1426899640-6599-1-git-send-email-mjguzik@gmail.com> <1426899640-6599-2-git-send-email-mjguzik@gmail.com> <20150321015151.GF2379@kib.kiev.ua> <20150321015722.GC27736@dft-labs.eu> <20150321141832.GH2379@kib.kiev.ua> <20150321181931.GA14650@dft-labs.eu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 21, 2015 at 07:19:31PM +0100, Mateusz Guzik wrote:
> On Sat, Mar 21, 2015 at 04:18:32PM +0200, Konstantin Belousov wrote:
> > On Sat, Mar 21, 2015 at 02:57:22AM +0100, Mateusz Guzik wrote:
> > > On Sat, Mar 21, 2015 at 03:51:51AM +0200, Konstantin Belousov wrote:
> > > > On Sat, Mar 21, 2015 at 02:00:38AM +0100, Mateusz Guzik wrote:
> > > > > From: Mateusz Guzik <mjg@freebsd.org>
> > > > > 
> > > > > Prior to this change the kernel would take p1's credentials and assign
> > > > > them tempororarily to p2. But p1 could change credentials at that time
> > > > > and in effect give us a use-after-free.
> > > > In which way could it change the credentials ?  The assigned credentials
> > > > are taken from td_ucred, which, I thought, are guaranteed to be stable
> > > > for the duration of a syscall.
> > > > 
> > > 
> > > It takes thread's credential in do_fork. But initial copy is taken
> > > unlocked from struct proc.
> > > 
> > > Relevant part of the diff:
> > > > > @@ -870,7 +867,7 @@ fork1(struct thread *td, int flags, int pages, struct proc **procp,
> > > > >  	 * XXX: This is ugly; when we copy resource usage, we need to bump
> > > > >  	 *      per-cred resource counters.
> > > > >  	 */
> > > > > -	proc_set_cred(newproc, p1->p_ucred);
> > > > > +	proc_set_cred(newproc, crhold(td->td_ucred));
> > > > >  
> > 
> > I do not understand your note, nor I see the chunk above in the patches
> > you send.  Below is the citation from the patch 1:
> > 
> > @@ -410,9 +410,6 @@ do_fork(struct thread *td, int flags, struct proc *p2,      
> > +struct thread *td2,                                                            
> >         bzero(&p2->p_startzero,                                                 
> >             __rangeof(struct proc, p_startzero, p_endzero));                    
> >                                                                                 
> > -       crhold(td->td_ucred);                                                   
> > -       proc_set_cred(p2, td->td_ucred);                                        
> > -                                                                               
> 
> fork1 does:
> 
>         proc_set_cred(newproc, p1->p_ucred);
> 
> p1 is unlocked, so whatever memory p1->p_ucred points to may already be
> freed.
> 
>         /*
>          * Initialize resource accounting for the child process.
>          */
>         error = racct_proc_fork(p1, newproc);
>         if (error != 0) {
>                 error = EAGAIN;
>                 goto fail1;
>         }
> 
> racct_proc_fork -> racct_add_locked results in accessing such
> now-possibly-freed credentials.
> 
> do_fork which properly assigns credentials (from a stable source
> (td_ucred) + grabs a reference) is called later.
> 
> The patch in question moves aforementioned assignent earlier to replace
> unsafe one with p1->p_ucred.

It seems that I understand now.

If you instead assign td->td_ucred for the new process p_ucred temporary,
would it allow to avoid introducing fail2 label ?  I dislike even more
contrived cleanup after the patch.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150321192904.GQ2379>