Re: [musl] execvp() behaviour with unrecognized file header

[Rich Felker <dalias@libc.org>]

On Thu, Feb 13, 2020 at 09:11:03PM +0100, Markus Wichmann wrote:
> Hi all,
> 
> so I had a look around at other implementations, since I thought the
> problem might be a solved one, and here's what I found:
> 
> newlib does not support this behavior at all.
> 
> bionic uses a VLA for the new argv[]. I didn't even know C++ had VLAs,
> so at least I learned something from this.
> 
> glibc also uses a VLA.
> 
> klibc also does not support this behavior.
> 
> uclibc-ng is an interesting one. On architectures with MMU they allocate
> the necessary space with alloca(), but without an MMU, they will use
> mmap() directly to try and minimize the memory leak, as a comment
> directly before the code responsible tells us.

This makes no sense. alloca does not cause any memory leak; it just
blows away the stack if the stack isn't sufficiently large. On the
other hand mmap is a memory leak without some dirty tricks to get rid
of the leak. You could either use synchronization, taking advantage of
shared memory with parent, to allocate a single mmap that's reused
(and possibly resized) every time there's a vfork child calling
execvp, but otherwise left around (bounded usage so not a "leak"), or
you could stick a hook in the parent side of vfork that checks for a
thread-local mmap execvp buffer pointer and unmaps it before return in
the parent if it's found.

> So yeah, the competition appears to either not bother or just use VLAs.
> I guess it is not a huge problem in practice?

Using VLAs is worse than not supportint it at all -- it's an
exploitable vuln.

Rich