Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 6 Mar 2019 14:30:00 -0700
From:   Tycho Andersen <tycho@tycho.ws>
To:     Christian Brauner <christian.brauner@canonical.com>
Cc:     Kees Cook <keescook@chromium.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        stable@vger.kernel.org
Subject: Re: [PATCH 2/2] seccomp: disallow NEW_LISTENER and TSYNC flags
Message-ID: <20190306213000.GI7413@cisco>
References: <20190306201413.14153-1-tycho@tycho.ws>
 <20190306201413.14153-2-tycho@tycho.ws>
 <20190306203932.im7lkblvmd227td3@gmail.com>
 <20190306204611.GH7413@cisco>
 <CAPP7u0Wp6q=LwtnbNk3YNaKKHXAfDqXd0Dx6xXXesvKpR-p+Gg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPP7u0Wp6q=LwtnbNk3YNaKKHXAfDqXd0Dx6xXXesvKpR-p+Gg@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Mar 06, 2019 at 10:02:25PM +0100, Christian Brauner wrote:
> On Wed, Mar 6, 2019 at 9:46 PM Tycho Andersen <tycho@tycho.ws> wrote:
> >
> > On Wed, Mar 06, 2019 at 09:39:35PM +0100, Christian Brauner wrote:
> > > > +
> > > >     /* Prepare the new filter before holding any locks. */
> > > >     prepared = seccomp_prepare_user_filter(filter);
> > > >     if (IS_ERR(prepared))
> > > > @@ -1302,7 +1315,7 @@ static long seccomp_set_mode_filter(unsigned int flags,
> > > >             mutex_unlock(&current->signal->cred_guard_mutex);
> > > >  out_put_fd:
> > > >     if (flags & SECCOMP_FILTER_FLAG_NEW_LISTENER) {
> > > > -           if (ret < 0) {
> > > > +           if (ret) {
> > >
> > > Why that change but keep checking if (ret < 0) further up?
> >
> > Not sure what you mean here. The only other place I see that we check
> > something is < 0 in that function is the return value of
> > get_unused_fd_flags(), which looks right to me?
> 
> The change just seemed it had nothing to do with the rest of the patch.
> Just making sure this didn't happen on accident and would cause regressions.

No, not on accident :). See the second half of the patch notes.

I can split it out into two separate patches if that makes more sense.
In fact this hunk alone fixes the UAF, but you still get non-sensical
return results even if it doesn't do anything terrible, hence the
first hunk.

Cheers,

Tycho