From owner-freebsd-current@FreeBSD.ORG Sat Mar 21 19:29:14 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B42D9136; Sat, 21 Mar 2015 19:29:14 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D1CEE37; Sat, 21 Mar 2015 19:29:14 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2LJT4F2002174 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 21 Mar 2015 21:29:04 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2LJT4F2002174 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2LJT4Lm002173; Sat, 21 Mar 2015 21:29:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Mar 2015 21:29:04 +0200 From: Konstantin Belousov To: Mateusz Guzik , jenkins-admin@freebsd.org, freebsd-current@freebsd.org, Mateusz Guzik Subject: Re: [PATCH 1/3] fork: assign refed credentials earlier Message-ID: <20150321192904.GQ2379@kib.kiev.ua> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150321181931.GA14650@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 19:29:14 -0000 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 > > > > > > > > > > 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.