Unexpeced exception when running aarch64 binary about qasan HOT 5 CLOSED

Can you shared the binary? If not, at lest the configuration with checksec

from qasan.

If you run ./qasan-qemu (not qasan, so without preloading libqasan) what happens? What happens if you use vanilla QEMU 3.1.1 (afl-qemu-trace from AFL++ is also ok)

from qasan.

If you run ./qasan-qemu (not qasan, so without preloading libqasan) what happens? What happens if you use vanilla QEMU 3.1.1 (afl-qemu-trace from AFL++ is also ok)

Hi:

The first one still crashes with the same output.

The second one runs and finishes normally.

Checksec output:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH������Symbols���������FORTIFY�Fortified�������Fortifiable�����FILE
Full RELRO      No canary found   NX enabled    PIE enabled     No RPATH   RUNPATH     83) Symbols������  No����0���������������3��������������� loader64

The binary is quite complex and links to multiple proprietary libraries. Can I send them to your email address andreafioraldi#gmail.com or some IM account?

from qasan.

Yes send it to [email protected]. If qasan-qemu crashes is a bit weird, it should behave like normal qemu if libqasan is not loaded.

from qasan.

Hi:

I think I've figured out the issue. The reason is not because of relevant libraries, it's because the way the binary was linked.

I found a warning is printed out when running the binary under normal qemu, because when linking it used

-Wl,-rpath,./lib64/lib64/ -L./lib64/lib64/

linker: normalize_path - invalid input: "./lib64/lib64/", the input path should be absolute
linker: Warning: unable to normalize "./lib64/lib64/"
WARNING: linker: Warning: unable to normalize "./lib64/lib64/"

Normal qemu may just ignore this linker warning and proceed, however qasan will crash instead, and the crash error is same as when a linking library is missing on ld search path. But if you fixed the linking warning, the binary runs normally.

To reproduce this issues, just mimic the library missing behavior:

~/android-ndk-r20b/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang test.c -o test -llog

But runs test without giving path to liblog.so will reproduce the same error:

CANNOT LINK EXECUTABLE "./test": library "liblog.so" not found
libc: CANNOT LINK EXECUTABLE "./test": library "liblog.so" not found
libc: Fatal signal 6 (SIGABRT), code -6 in tid 40210 (qasan-qemu)
QEMU-AddressSanitizer:DEADLYSIGNAL
=================================================================
==40210==ERROR: QEMU-AddressSanitizer: SEGV on unknown address 0x7f47d7345ad8 (pc 0x7f47d7345ad8 bp 0x7f47dbe60140 sp 0x7f47dbe60010 T40210)
    #0 0x7f47d7345ad8 in __dl___set_errno_internal __dl_sfp-exceptions.c:?

QEMU-AddressSanitizer can not provide additional info.
SUMMARY: QEMU-AddressSanitizer:  in __dl___set_errno_internal __dl_sfp-exceptions.c:?
==40210==ABORTING
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
[1]    40210 segmentation fault  ./qasan ./test

The following command line works fine.

LD_LIBRARY_PATH=$ANDROID_NDK/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android:$ANDROID_PATH/lib64 ./qasan-qemu ./test

So I suspect the reason is qasan may lead to different logic in linker, so when normally linker will tolerate relative searching path, qasan environment treat it as error such as the linker does not accept the path, lead to library loading error.

After I changed the linking search path to absolute it runs happily. Great job!

from qasan.