[PATCH] posix: Remove dynamic memory allocation from execl{e,p}

Florian Weimer fweimer@redhat.com
Fri Jan 29 13:58:00 GMT 2016


On 01/29/2016 02:53 PM, Adhemerval Zanella wrote:
> GLIBC execl{e,p} implementation might use malloc if the total number of
> arguments exceeds initial assumption size (1024).  This might lead to
> issues in two situations:
> 
> 1. execl/execle is stated to be async-signal-safe by POSIX [1].  However
>    if it is used in a signal handler with a large argument set (that
>    may call malloc internally) and the resulting call fails, it might
>    lead malloc in the program in a bad state.
> 
> 2. If the functions are used in a vfork/clone(VFORK) situation it also
>    might break internal malloc state from parent.
> 
> This patch fixes it by using stack allocation instead.  It fixes
> BZ#19534.

I would rather see a variant of struct scratch_buffer which uses mmap
for the fallback allocation, and use it here, rather than imposing
arbitrary limits.  It's not clear to me at all if __MAX_ALLOCA_CUTOFF is
a reasonable value inside a signal handler.

Florian



More information about the Libc-alpha mailing list