[PATCH v2 5/5] elf: Use dl_scratch_buffer for LD_LIBRARY_PATH copy in _dl_init_paths

[Adhemerval Zanella Netto]

On 15/05/26 15:21, Adhemerval Zanella wrote:
> _dl_init_paths used strdupa to make a mutable copy of LD_LIBRARY_PATH
> for fillin_rpath to tokenize.  The env block is attacker-controllable
> and Linux allows individual variables up to MAX_ARG_STRLEN (32 *
> PAGE_SIZE = 128 KB), so the strdupa can push tens of KB onto the
> loader's startup stack on top of the env block that already sits on
> the initial stack.  With a reduced RLIMIT_STACK the doubled copy
> overflows before main () is reached.
> 
> Replace the strdupa with a dl_scratch_buffer: short paths stay in
> the 256-byte inline area, longer ones spill to anonymous mmap (malloc
> is not yet available during _dl_init_paths).  Two follow-on changes
> make the new scratch lifetime safe against _dl_signal_error:
> 
>   * Count entries directly off the const LD_LIBRARY_PATH and allocate
>     __rtld_env_path_list.dirs *before* the scratch is live.  That way
>     the larger of the two heap allocations the loader controls signals
>     its OOM with no scratch to leak.
> 
>   * Convert fillin_rpath to return bool instead of calling
>     _dl_signal_error internally on per-entry malloc failure.  Its
>     only caller in the LLP path now frees the scratch first and then
>     signals the error from a clean state.  decompose_rpath, the other
>     caller, is updated symmetrically.  This also fixes a pre-existing
>     leak in fillin_rpath's OOM path, where the to_free heap copy from
>     expand_dynamic_string_token was not released before the
>     _dl_signal_error.
> 
> Checked on x86_64-linux-gnu, aarch64-linux-gnu, and i686-linux-gnu.
> 
> Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
The CI failure is the I created the test with --enable-hardcoded-path-in-tests,
while the bots does not use the configure option.  This leads to different
assumptions for the area reserved for LD_LIBRARY_PATH or --library-path.

I will send a new version.