Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4147190yba; Tue, 23 Apr 2019 16:19:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqzDfZzOJczK2JWfZTF95uX5Mk4P1t+M5GtHk/XXWunbxDni7uaw0fuAxqQCIZQ6qLNzYOyr X-Received: by 2002:a63:be02:: with SMTP id l2mr27594167pgf.48.1556061554438; Tue, 23 Apr 2019 16:19:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556061554; cv=none; d=google.com; s=arc-20160816; b=yUNMWOtkma6xCKoTs/e5bSA5jF0kSAXDW/tErs0gJQnFV25R+DSb0P6c223Qr7ms2t BJOYzrym1YVry6b44YSo28paF5Wx4u+ZXFI2mcuOau3zEXzffSAFhpwu7z3XYfuJq2N8 XTdIThKrpzwmIyK0NNYAAln5uKqygHMnqLQYhKartTSoNtivKwWhG+BYYy2St4gXJW0+ 8lgsrs+w6+J00ymymCLwcVMd9YZgnRH5h/+3tl3Kv4P6wQhFa1eYLkC4SLjIFuWW5L5V 8mcmAqTCnpe4TF87tIm6ZWZQ+kyrsaxW8Phh3uPv72FjnM3rGkrifExG2RMonVczINhf x2Ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=MDOMrSjUhEGxWPA8lvoVi0M1qXMQV+HMjOUFLi4vNc4=; b=TzgKBbOKVM917Rcohz12BWa879MSobH4f90ijL47RT7WzgD01ErUzDZqr2N0tar80x N9RwkQchJiIfQxi5euiPf9057DcnuJnWN7Lv7YTAoE9v+aCQQTQza21AQC3zd6Q3WJDr X0Rrh5zJCCC3qBDhBy0X5kU0Okwsi7Y7siK91BHrq0og1yZ869ohBMrGKOqg0kgPweJi GeazyQlC9iSN6rU0GkMHTgfO/YsTRF2cHMkfm2+U0jRJRjVMqblu8SwatGSKivogs9Vj 3KiGjzFFNtdzhf06AqYg0phZAlJkU3dycONV3ttl9P40OlMIWjB69Tzq+f7kQKDR/rXI LWoQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p8si243048pfi.286.2019.04.23.16.18.58; Tue, 23 Apr 2019 16:19:14 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728470AbfDWXSI (ORCPT + 99 others); Tue, 23 Apr 2019 19:18:08 -0400 Received: from namei.org ([65.99.196.166]:35470 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726339AbfDWXSH (ORCPT ); Tue, 23 Apr 2019 19:18:07 -0400 Received: from localhost (localhost [127.0.0.1]) by namei.org (8.14.4/8.14.4) with ESMTP id x3NNI430029385; Tue, 23 Apr 2019 23:18:04 GMT Date: Wed, 24 Apr 2019 09:18:04 +1000 (AEST) From: James Morris To: Kees Cook cc: Tycho Andersen , LKML , "# 3.4.x" Subject: Re: [PATCH 2/2] seccomp: disallow NEW_LISTENER and TSYNC flags In-Reply-To: Message-ID: References: <20190306201413.14153-1-tycho@tycho.ws> <20190306201413.14153-2-tycho@tycho.ws> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 23 Apr 2019, Kees Cook wrote: > Thanks! Sorry I missed this. James, can you take this for Linus's > fixes for v5.1? (Or should I send a pull request to you?) > > Acked-by: Kees Cook These are standalone for v5.1 fixes currently so you can send them directly to Linus. > > Let's also add: > > Reported-by: syzbot+b562969adb2e04af3442@syzkaller.appspotmail.com > > > --- > > kernel/seccomp.c | 17 +++++++++++++++-- > > 1 file changed, 15 insertions(+), 2 deletions(-) > > > > diff --git a/kernel/seccomp.c b/kernel/seccomp.c > > index d0d355ded2f4..79bada51091b 100644 > > --- a/kernel/seccomp.c > > +++ b/kernel/seccomp.c > > @@ -500,7 +500,10 @@ seccomp_prepare_user_filter(const char __user *user_filter) > > * > > * Caller must be holding current->sighand->siglock lock. > > * > > - * Returns 0 on success, -ve on error. > > + * Returns 0 on success, -ve on error, or > > + * - in TSYNC mode: the pid of a thread which was either not in the correct > > + * seccomp mode or did not have an ancestral seccomp filter > > + * - in NEW_LISTENER mode: the fd of the new listener > > */ > > static long seccomp_attach_filter(unsigned int flags, > > struct seccomp_filter *filter) > > @@ -1256,6 +1259,16 @@ static long seccomp_set_mode_filter(unsigned int flags, > > if (flags & ~SECCOMP_FILTER_FLAG_MASK) > > return -EINVAL; > > > > + /* > > + * In the successful case, NEW_LISTENER returns the new listener fd. > > + * But in the failure case, TSYNC returns the thread that died. If you > > + * combine these two flags, there's no way to tell whether something > > + * succeded or failed. So, let's disallow this combination. > > also a tiny typo: succeeded > > > + */ > > + if ((flags & SECCOMP_FILTER_FLAG_TSYNC) && > > + (flags && SECCOMP_FILTER_FLAG_NEW_LISTENER)) > > + return -EINVAL; > > + > > /* 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(¤t->signal->cred_guard_mutex); > > out_put_fd: > > if (flags & SECCOMP_FILTER_FLAG_NEW_LISTENER) { > > - if (ret < 0) { > > + if (ret) { > > listener_f->private_data = NULL; > > fput(listener_f); > > put_unused_fd(listener); > > -- > > 2.19.1 > > > > -Kees > > -- James Morris