[PATCH 2/6] elf: Add dl_scratch_buffer, a loader-side scratch buffer

[Adhemerval Zanella Netto]

On 13/05/26 18:18, H.J. Lu wrote:
> On Thu, May 14, 2026 at 3:20 AM Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>> Several loader code paths need a short-lived scratch buffer sized
>> by attacker-influenced inputs (RPATH entries, ld.so.cache strings,
>> etc.).  The available primitives are all unsuitable:
>>
>>   - alloca is unbounded and can overflow PTHREAD_STACK_MIN stacks.
>>
>>   - <scratch_buffer.h> is unaware of __minimal_malloc: a malloc'd
>>     spill freed during early loader startup silently leaks because
>>     __minimal_free only releases the most-recent allocation.
>>
>>   - A few paths cannot route through the interposable malloc at
>>     all -- ld.so.cache lookup in particular, because an interposed
>>     user malloc may recursively call dlopen and __munmap the cache
>>     mapping mid-copy (commit ccdb048d, "Fix recursive dlopen").
>>
>> Add a loader-side analogue of <scratch_buffer.h>: a 256-byte inline
>> area for the common case, with spill to malloc by default or to
>> anonymous mmap when __minimal_malloc is active or the caller passes
>> DL_SCRATCH_NO_MALLOC.  Mmap spills are tagged " glibc: loader
>> scratch" via __set_vma_name for /proc/self/maps visibility.  On OOM
>> dl_scratch_buffer_grow raises a loader error via _dl_signal_error
>> and does not return.
> 
> Is it possible to share 2 implementations?
The dl_scratch_buffer just hide the machinery required to check if
libc malloc is active, otherwise allocate using mmap/munmap.  The only
usage where mmap is always required is one where it explicitly avoids
malloc to work on interposable ones.

We can open-code each of one, but this makes slight more simple.  I
also tried to evaluate a way to tied this scratch buffer with the
exception mechanism, so wen _dl_signal_error is thrown it would
be automatically deallocate.  But I couldn't think in a simple way
to accomplish it, we are essentially emulating a C++ exception handling
using setjmp/longjmp it is complex for a reason.