Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 13 Feb 2020 18:21:03 -0500
From: Rich Felker <>
Subject: Re: execvp() behaviour with unrecognized file header

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.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.