[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