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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

> Em 29 de jan de 2016, Ãs 11:58, Florian Weimer <fweimer@redhat.com> escreveu:
> 
>> 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
> 

I agree that __MAX_ALLOCA_CUTOFF is arbitrary and does not solve anything (for instance it does not impose constraints for deep stacked calls).

Also mmap usage does not solve the second case (vfork/clone) in case of exec success since the call won't unmap the region.