[TUHS] Exec With 0 and NULL argc and argv? (was: the first busybox)

segaloco via TUHS tuhs at tuhs.org
Fri Oct 23 08:26:13 AEST 2026


On Thursday, October 22nd, 2026 at 15:13, Steffen Nurpmeso via TUHS <tuhs at tuhs.org> wrote:

> Too much honour.  I think we were once there in the past already.
> K&R says in "5.10 Command-line Arguments"
> 
>   By convention, argv[0] is the name by which the program was
>   invoked, so argc is at least 1.
> 
> But in 2021 there was CVE-2021-4034 --- through execve(2) one
> could enforce another condition, and that caused quite some
> trouble.  Now, if i ask Google AI it says
>
> [insert AI digest here detailing kernel/execs supporting argc == 0]
> 
> ...
> 
> --steffen

Ah that all makes a bit more sense...so it's more about various kernels
allowing a process to be exec'd without compliant argc/argv passing
rather than legitimate situations where it's completely reasonable to
expect these to be 0/NULL it seems.  That's what I get from your AI
digest anyway.

So at the end of the day the problem being solved is the fact that,
despite standards committees' best efforts, many kernels and exec
mechanisms seem to let you get into this messy state?  I'm just
surprised that the solution is yet another call rather than kernels just
getting cleaned up to prevent this.  Is there some legitimate reason to
exec something and zero out the argument info?  Is the new function
added as to not break applications that *do* depend on argc == 0 despite
it being recognized as generally bad all around in a hosted environment?

- Matt G.


More information about the TUHS mailing list