Initially reported downstream in Gnetoo at https://bugs.gentoo.org/850691. I've bisected it to: ``` ``` f5f7144dfcbf2a11fd2c17316c213928307c1db3 is the first bad commit commit f5f7144dfcbf2a11fd2c17316c213928307c1db3 Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Fri Jun 15 16:14:58 2018 +0100 rtld: Use generic argv adjustment in ld.so [BZ #23293] When an executable is invoked as ./ld.so [ld.so-args] ./exe [exe-args] then the argv is adujusted in ld.so before calling the entry point of the executable so ld.so args are not visible to it. On most targets this requires moving argv, env and auxv on the stack to ensure correct stack alignment at the entry point. This had several issues: - The code for this adjustment on the stack is written in asm as part of the target specific ld.so _start code which is hard to maintain. - The adjustment is done after _dl_start returns, where it's too late to update GLRO(dl_auxv), as it is already readonly, so it points to memory that was clobbered by the adjustment. This is bug 23293. - _environ is also wrong in ld.so after the adjustment, but it is likely not used after _dl_start returns so this is not user visible. - _dl_argv was updated, but for this it was moved out of relro, which changes security properties across targets unnecessarily. This patch introduces a generic _dl_start_args_adjust function that handles the argument adjustments after ld.so processed its own args and before relro protection is applied. The same algorithm is used on all targets, _dl_skip_args is now 0, so existing target specific adjustment code is no longer used. The bug affects aarch64, alpha, arc, arm, csky, ia64, nios2, s390-32 and sparc, other targets don't need the change in principle, only for consistency. The GNU Hurd start code relied on _dl_skip_args after dl_main returned, now it checks directly if args were adjusted and fixes the Hurd startup data accordingly. Follow up patches can remove _dl_skip_args and DL_ARGV_NOT_RELRO. Tested on aarch64-linux-gnu and cross tested on i686-gnu. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> (cherry picked from commit ad43cac44a6860eaefcadadfb2acb349921e96bf) elf/rtld.c | 73 +++++++++++++++++++++++++++++++++++-------- sysdeps/mach/hurd/dl-sysdep.c | 30 ++++++++---------- 2 files changed, 73 insertions(+), 30 deletions(-) ``` (Ignore the date, it was only committed a few weeks ago).
I can reproduce if I run the final command manually (LC_ALL=C gdb --args ./ld.so.1 --library-path . /usr/bin/cal, in /var/tmp/portage/sys-libs/glibc-2.35-r7/image/lib) using the just-built glibc. ``` Program received signal SIGSEGV, Segmentation fault. 0xf8f0405c in ?? () from ./libc.so.6 (gdb) bt #0 0xf8f0405c in ?? () from ./libc.so.6 #1 0xf8f044cc in ?? () from ./libc.so.6 #2 0xf8f04588 in getopt_long () from ./libc.so.6 #3 0xf9690084 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) ``` Not very helpful.
To be clear, this is from using the 2.35 branch. Last good commit on release/2.35: a8e9b5b8079d18116ca69c9797e77804ecf2ee7e Last bad commit on release/2.35: d7d1eebd4d5806be55ffacbf18917ad68d4ae7fd Then bisected to release/2.35: f5f7144dfcbf2a11fd2c17316c213928307c1db3.
azanella found the dupe, thanks! *** This bug has been marked as a duplicate of bug 29165 ***