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: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Christos Zoulas <christos%zoulas.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost
Subject: Re: kern/56673: don't allow execve with NULL argv
Date: Mon, 31 Jan 2022 22:43:18 +0700
Date: Mon, 31 Jan 2022 09:41:14 -0500
From: Christos Zoulas <christos%zoulas.com@localhost>
Message-ID: <12E23D1B-F51B-44F2-B4C0-D950415B4863%zoulas.com@localhost>
| I see this as an instance of a non-conforming environment
It isn't.
| The fact that the documentation explicitly does not call having argc != 0
| and argv[0] pointing to valid memory out *yet*
The latter (pointing to invalid memory) isn't an issue, if the caller
of an exec function supplies a nonsense argv[0] they'll either get a
SIGSETV or an EFAULT, just like any other syscall where a pointer to
invalid memory is provided. If the kernel is supplying an invalid
pointer to an exec'd application, then it (the kernel) is simply broken,
which no test we can reasonably insert can prevent (but which, for this
issue anyway, doesn't happen).
As for *yet* for the former (argc > 0) I see no signs of that ever
changing - it is clear from what is already there, that the issue of
sending no args at all was very well understood by some earlier set
of standards writers (I don't have copies of anything old enough to
determine when that was first added) and yet there was no attempt to
force the world to change at that time (and this would have been an
easy change to make, as in practice, no-one normally ever exec's
something with no args at all, so they would have not been breaking
anything, unlike some of the other changes that have been made).
It is a bit hard to imagine that anyone is about to change that now.
| I see it simply as putting a check in one place instead of forcing
| everyone to be check for it. It is good hygiene.
Exactly the same can be said about making *NULL "work" properly.
We can (and once it was done) fix the kernel to that *NULL == '\0'
(and if needed is zero for any reasonable width of data access - ie:
provide a page of all 0's at 0), which would save all of those
if (p != NULL) tests that we currently need to make. Not sure doing
that counts as good hygiene though, in either case.
kre
Home |
Main Index |
Thread Index |
Old Index