MSAN: Memory initialization from `syscall` is not supported

[pkillarjun]

Built environment

$ clang -v
clang version 18.1.8 (Fedora 18.1.8-1.fc40)
Target: x86_64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Configuration file: /etc/clang/x86_64-redhat-linux-gnu-clang.cfg
System configuration file directory: /etc/clang/
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/14
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/14
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

$ ldd --version
ldd (GNU libc) 2.39
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

$ uname -a
Linux fedora 6.11.4-201.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Oct 20 15:04:22 UTC 2024 x86_64 GNU/Linux

test code

/* msan_syscall.c */

#include <stdio.h>
#include <unistd.h>
#include <sys/syscall.h>

int main(void)
{
    int ret;
    char seed[16];

    ret = syscall(SYS_getrandom, seed, sizeof(seed), 0);
    if (ret == -1)
        return 1;

    /* Why this crash? */
    for (int i = 0; i < 16; i++) {
        printf("%02x ", seed[i]);
    }
    printf("\n");

    return 0;
}

compile and run

$ clang -fsanitize=memory msan_syscall.c -o msan_syscall

$ ./msan_syscall 
==34754==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x4c85fb in main (/home/down/Desktop/msan_syscall+0x4c85fb) (BuildId: 1c5b4d60c70579fa8bf0feecc8b63432c00c4e68)
    #1 0x7f1cddafe087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: 77c77fee058b19c6f001cf2cb0371ce3b8341211)
    #2 0x7f1cddafe14a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: 77c77fee058b19c6f001cf2cb0371ce3b8341211)
    #3 0x430304 in _start (/home/down/Desktop/msan_syscall+0x430304) (BuildId: 1c5b4d60c70579fa8bf0feecc8b63432c00c4e68)

SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/down/Desktop/msan_syscall+0x4c85fb) (BuildId: 1c5b4d60c70579fa8bf0feecc8b63432c00c4e68) in main

gdb

Breakpoint 1, main () at msan_syscall.c:9
9           int ret;
(gdb) c
Continuing.

Breakpoint 2, main () at msan_syscall.c:12
12          ret = syscall(SYS_getrandom, seed, sizeof(seed), 0);
(gdb) p seed
$5 = '\000' <repeats 15 times>
(gdb) c
Continuing.

Breakpoint 3, main () at msan_syscall.c:17
17          for (int i = 0; i < 16; i++) {
(gdb) p seed
$6 = "\225\245\357\234\361\035\020|\271\217q\246Ò\245", <incomplete sequence \351>

Ping @vitalybuka

[vitalybuka]

Syscalls support is very basic, it's essensically to the user to unpoison.

There are hooks for some syscalls

llvm-project/compiler-rt/include/sanitizer/linux_syscall_hooks.h

Line 16 in f8535fd

// __sanitizer_syscall_pre_getfoo(...args...);

[pkillarjun]

Syscalls support is very basic, it's essensically to the user to unpoison.

This does make a bit of sense, but it's bad for mainstream projects; nobody likes adding random gibberish code into their codebase.

There are hooks for some syscalls

If so, I hope soon there will be a hook for SYS_getrandom.

[pkillarjun]

Ah, looks like I am not the only one #111847.

You know, I wondered how hard it could be to write an "interceptor." Well, it turned out it is pretty confusing due to macros.
I wanted to jump off a cliff while trying to understand interceptor macros—it was only that hard.

[pkillarjun]

I wanted to jump off a cliff

Hopefully, I won't get banned.

[vitalybuka]

Ah, looks like I am not the only one #111847.

That one is unrelated, missing interceptors.

Writing an interceptor is easy, writing interceptor for "syscall" is hard.
Should be possible but we never needed.

[pkillarjun]

Ah, looks like I am not the only one #111847.

That one is unrelated, missing interceptors.

Oh, okay. So basically #114377 and #111847 are the same.

Writing an interceptor is easy, writing interceptor for "syscall" is hard. Should be possible but we never needed.

alright.

[vitalybuka]

Oh, okay. So basically #114377 and #111847 are the same.

Yes, very similar.