[BUG] Stack smashing detected

[lurtz]

Description
Running any program results in

*** stack smashing detected ***: terminated

Steps to Reproduce

1. Download v2.0.0-beta2 SDK
2. Extract it to e.g. ~/Downloads/fastdev-sdk-trixie-ebclfsa-ebcl-qemuarm64
3. Execute e.g. ./aarch64-linux-gnu-g++ --help

Expected Behavior
No crash but e.g. help text.

Actual Behavior

A crash

$ ./aarch64-linux-gnu-g++ --help
*** stack smashing detected ***: terminated

Environment

• OS: Ubuntu 24.04
• SDK version: v2.0.0-beta2
• Build preset:

Additional Context
Any other relevant information, logs, or screenshots.

[lurtz]

Further analysis shows that the SDK has been compiled with a newer glibc version and linker as available on the host. For loading libraries this is not an issue because $ORIGIN can be used in elf files for relative paths. The linker (INTERP in elf), does not support this and thus the host linker is used, which is either not a matching version or just too old.

The old version of the SDK used the host linker and glibc. It also did not seem to make use of RPATH in most libraries.

[opajonk]

Analysis

Assume for the following that $pwd is the root of an exported sysroot, like the unpacked fastdev-sdk-trixie-ebclfsa-ebcl-qemuarm64.tar.gz.

Then:

$ binary=usr/bin/aarch64-linux-gnu-ld
$ readelf -d $binary | grep -E 'NEEDED|RPATH|RUNPATH'
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../lib:$ORIGIN/../lib/x86_64-linux-gnu]
 0x0000000000000001 (NEEDED)             Shared library: [libbfd-2.44-arm64.so]
 0x0000000000000001 (NEEDED)             Shared library: [libctf-arm64.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libjansson.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
$ readelf -l  $binary  | grep 'interpreter'
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

Reproducing this bug is now easy on a host where /lib64/ld-linux-x86-64.so.2 (an absolute path, hence on the host) is incompatible with the libc.so.6 found on the library rpath of the $binary. Since the rpath is relative to the executable, it will find the libc.so.6 of the sysroot. Running the executable (in this case) crashes in the following way:

$ $binary
*** stack smashing detected ***: terminated
Aborted (core dumped)
$

There are several possible solutions, but one seems most elegant: pin by default the libc.so.6 to the one of the host as well, just like the INTERP. The pinning of the INTERP cannot be changed; libc.so.6 and the interpreter must match, so this is the sensible thing to do:

$ patchelf --replace-needed libc.so.6 /lib/x86_64-linux-gnu/libc.so.6 $binary
$ readelf -d $binary | grep -E 'NEEDED|RPATH|RUNPATH'
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../lib:$ORIGIN/../lib/x86_64-linux-gnu]
 0x0000000000000001 (NEEDED)             Shared library: [libbfd-2.44-arm64.so]
 0x0000000000000001 (NEEDED)             Shared library: [libctf-arm64.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libjansson.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [/lib/x86_64-linux-gnu/libc.so.6]
$ ldd $binary
        linux-vdso.so.1 (0x000071597fd49000)
        libbfd-2.44-arm64.so => $pwd/usr/bin/../lib/x86_64-linux-gnu/libbfd-2.44-arm64.so (0x000071597f891000)
        libctf-arm64.so.0 => $pwd//usr/bin/../lib/x86_64-linux-gnu/libctf-arm64.so.0 (0x000071597fd10000)
        libjansson.so.4 => $pwd//usr/bin/../lib/x86_64-linux-gnu/libjansson.so.4 (0x000071597fd00000)
        /lib/x86_64-linux-gnu/libc.so.6 (0x000071597f600000)
        libz.so.1 => $pwd//usr/bin/../lib/x86_64-linux-gnu/libz.so.1 (0x000071597fcde000)
        libzstd.so.1 => $pwd//usr/bin/../lib/x86_64-linux-gnu/libzstd.so.1 (0x000071597f536000)
        libsframe.so.1 => $pwd//usr/bin/../lib/x86_64-linux-gnu/libsframe.so.1 (0x000071597fcd5000)
        /lib64/ld-linux-x86-64.so.2 (0x000071597fd4b000)
$ $binary
usr/bin/aarch64-linux-gnu-ld: no input files
$

This is not fully clean, of course. It leaves the runtime linker and libc.so.6 always coming from the host, while the rest of the shared libraries (correctly!) come from the exported sysroot. This is the best of both worlds, though:

1. The exported sysroot works out of the box 99% of the time, with the correct shared libraries used - except libc.so.6. Especially tricky ones like libctf-arm64.so.0 in the above example, which does not necessarily exist on the host, are correctly used. All usually works as intended. Only in case of a breaking change of the libc.so.6 between the host and the sysroot, a problem would arise. Given the fact that libc.so.6 does quite a few tricks to stay compatible, this is not a highly probable case.
2. When after extraction properly using the provided relocate-sdk.sh (as one should do for this kind of sysroot), this pinning of the full path to the hosts libc.so.6 can be reverted. The INTERP will be updated by the script to the full path to the runtime linker of the exported sysroot, and the linker and libc.so.6 will match again - and both correctly come from the sysroot. All executables and shared libraries come from the sysroot, and no part of the host "leaks in". All definitely works as intended.

[opajonk]

As an additional fix, we should change the relocate-sdk.sh in such a way that it uses the patchelf command from the sysroot. That way, the dependencies on the host are minimized.

[opajonk]

This will be fixed in the next release of the Toolkit.