All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: lkp@lists.01.org
Subject: Re: [fs/exec] 80bd5afdd8: xfstests.generic.633.fail
Date: Mon, 31 Jan 2022 14:49:36 -0800	[thread overview]
Message-ID: <202201311447.4A1CCAF@keescook> (raw)
In-Reply-To: <20220131135940.20790cff1747e79dd855aaf4@linux-foundation.org>

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

On Mon, Jan 31, 2022 at 01:59:40PM -0800, Andrew Morton wrote:
> On Mon, 31 Jan 2022 18:13:44 +0100 Christian Brauner <brauner@kernel.org> wrote:
> 
> > > in other words, the changes that you see CMD_ARGS[0] == NULL for
> > > execveat() seem higher than for path-based exec.
> > > 
> > > To counter that we should probably at least update the execveat()
> > > manpage with a recommendation what CMD_ARGS[0] should be set to if it
> > > isn't allowed to be set to NULL anymore. This is why was asking what
> > > argv[0] is supposed to be if the binary doesn't take any arguments.
> > 
> > Sent a fix to our fstests now replacing the argv[0] as NULL with "".
> 
> As we hit this check so quickly, I'm thinking that Ariadne's patch
> "fs/exec: require argv[0] presence in do_execveat_common()" (which
> added the check) isn't something we'll be able to merge into mainline?

I think the next best would be to mutate an NULL argv into { "", NULL }.
However, I still think we should do the pr_warn().

Thoughts?

-- 
Kees Cook

WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Christian Brauner <brauner@kernel.org>,
	Matthew Wilcox <willy@infradead.org>,
	kernel test robot <oliver.sang@intel.com>,
	Ariadne Conill <ariadne@dereferenced.org>,
	0day robot <lkp@intel.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Rich Felker <dalias@libc.org>,
	Eric Biederman <ebiederm@xmission.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@lists.01.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, stable@vger.kernel.org
Subject: Re: [fs/exec]  80bd5afdd8: xfstests.generic.633.fail
Date: Mon, 31 Jan 2022 14:49:36 -0800	[thread overview]
Message-ID: <202201311447.4A1CCAF@keescook> (raw)
In-Reply-To: <20220131135940.20790cff1747e79dd855aaf4@linux-foundation.org>

On Mon, Jan 31, 2022 at 01:59:40PM -0800, Andrew Morton wrote:
> On Mon, 31 Jan 2022 18:13:44 +0100 Christian Brauner <brauner@kernel.org> wrote:
> 
> > > in other words, the changes that you see CMD_ARGS[0] == NULL for
> > > execveat() seem higher than for path-based exec.
> > > 
> > > To counter that we should probably at least update the execveat()
> > > manpage with a recommendation what CMD_ARGS[0] should be set to if it
> > > isn't allowed to be set to NULL anymore. This is why was asking what
> > > argv[0] is supposed to be if the binary doesn't take any arguments.
> > 
> > Sent a fix to our fstests now replacing the argv[0] as NULL with "".
> 
> As we hit this check so quickly, I'm thinking that Ariadne's patch
> "fs/exec: require argv[0] presence in do_execveat_common()" (which
> added the check) isn't something we'll be able to merge into mainline?

I think the next best would be to mutate an NULL argv into { "", NULL }.
However, I still think we should do the pr_warn().

Thoughts?

-- 
Kees Cook

  reply	other threads:[~2022-01-31 22:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-27  0:07 [PATCH v3] fs/exec: require argv[0] presence in do_execveat_common() Ariadne Conill
2022-01-27  5:29 ` Kees Cook
2022-01-27 16:51   ` Eric W. Biederman
2022-01-31 14:43 ` [fs/exec] 80bd5afdd8: xfstests.generic.633.fail kernel test robot
2022-01-31 14:43   ` kernel test robot
2022-01-31 15:08   ` Christian Brauner
2022-01-31 15:08     ` Christian Brauner
2022-01-31 15:19     ` Matthew Wilcox
2022-01-31 15:19       ` Matthew Wilcox
2022-01-31 15:37       ` Christian Brauner
2022-01-31 15:37         ` Christian Brauner
2022-01-31 15:51         ` Matthew Wilcox
2022-01-31 15:51           ` Matthew Wilcox
2022-01-31 16:14           ` Christian Brauner
2022-01-31 16:14             ` Christian Brauner
2022-01-31 17:13             ` Christian Brauner
2022-01-31 17:13               ` Christian Brauner
2022-01-31 21:59               ` Andrew Morton
2022-01-31 21:59                 ` Andrew Morton
2022-01-31 22:49                 ` Kees Cook [this message]
2022-01-31 22:49                   ` Kees Cook
2022-02-01 13:28                   ` Christian Brauner
2022-02-01 13:28                     ` Christian Brauner
2022-02-01 13:28                 ` Christian Brauner
2022-02-01 13:28                   ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202201311447.4A1CCAF@keescook \
    --to=keescook@chromium.org \
    --cc=lkp@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.