NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/56673: don't allow execve with NULL argv

The following reply was made to PR kern/56673; it has been noted by GNATS.

From: Jan Schaumann <>
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Wed, 26 Jan 2022 11:31:04 -0500

 Martin Husemann <> wrote:
 >  On Wed, Jan 26, 2022 at 03:55:01PM +0000, wrote:
 >  > I'd suggest to fail if the argv is NULL.
 >  I'm ambivalent here. Posix does allow it and the behaviour is well defined
 >  (if I didn't miss something).
 >  And setuid programs with stupid casts to unsigned (probably just added
 >  there to silence the compiler warning) are dangerous - and this is not
 >  a kernel issue.
 >  On the other hand there is probably no reasonable code out there that would
 >  use this, so rejecting it might be ok.
 If POSIX doesn't _require_ us to accept a NULL argv,
 then I think it's reasonable to reject it:
 ,----[ ]
 | Early proposals required that the value of argc passed
 | to main() be "one or greater". This was driven by the
 | same requirement in drafts of the ISO C standard. In
 | fact, historical implementations have passed a value
 | of zero when no arguments are supplied to the caller
 | of the exec functions. This requirement was removed
 | from the ISO C standard and subsequently removed from
 | this volume of POSIX.1-2017 as well. The wording, in
 | particular the use of the word should, requires a
 | Strictly Conforming POSIX Application to pass at least
 | one argument to the exec function, thus guaranteeing
 | that argc be one or greater when invoked by such an
 | application. In fact, this is good practice, since
 | many existing applications reference argv[0] without
 | first checking the value of argc.
 Just seems like the safer thing to do in the absence
 of a valid use case of a NULL argv.

Home | Main Index | Thread Index | Old Index