On Wed, Jan 26, 2022 at 02:59:52PM +0000, Matthew Wilcox wrote: > On Wed, Jan 26, 2022 at 11:44:47AM +0000, Ariadne Conill wrote: > > Interestingly, Michael Kerrisk opened an issue about this in 2008[1], > > but there was no consensus to support fixing this issue then. > > Hopefully now that CVE-2021-4034 shows practical exploitative use > > of this bug in a shellcode, we can reconsider. > > > > [0]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html > > [1]: https://bugzilla.kernel.org/show_bug.cgi?id=8408 > > Having now read 8408 ... if ABI change is a concern (and I really doubt > it is), we could treat calling execve() with a NULL argv as if the > caller had passed an array of length 1 with the first element set to > NULL. Just like we reopen fds 0,1,2 for suid execs if they were closed. I was having similar thoughts this morning. We can't actually change the argc, though, because of the various tests (see the debian code search links) that explicitly tests for argc == 0 in the child. But, the flaw is not the count, but rather that argv == argp in the argc == 0 case. (Or that argv NULL-checking iteration begins at argv[1].) But that would could fix easily by just adding an extra NULL. e.g.: Currently: argc = 1 argv = "foo", NULL envp = "bar=baz", ..., NULL argc = 0 argv = NULL envp = "bar=baz", ..., NULL We could just make the argc = 0 case be: argc = 0 argv = NULL, NULL envp = "bar=baz", ..., NULL We need to be careful with the stack utilization counts, though, so I'm thinking we could actually make this completely unconditional and just pad envp by 1 NULL on the user stack: argv = "what", "ever", NULL NULL envp = "bar=baz", ..., NULL My only concern there is that there may be some code out there that depends on envp immediately following the trailing argv NULL, so I think my preference would be to pad only in the argc == 0 case and correctly manage the stack utilization. -- Kees Cook
