A couple of sanitizer-related tweaks by mrc0mmand · Pull Request #41808 · systemd/systemd

mrc0mmand · 2026-04-24T13:12:47Z

The sanitizer job was FUBAR on Fedora Rawhide (and RHEL 10 to some extent) due to several changes:

latest LLVM (v22) introduced a change that occasionally generates a false-positive warning when running with sanitizers
several tools had to be "ASan-wrapped" because:
- util-linux started linking against libsystemd which propagated to other tools depending on its shared libraries (like libmount)
- libssh started depending on libfido2, which depends on libudev; this then translated to an interesting depedency chain where tpm2 utils got a dependency on libudev through libcurl -> libssh -> libfido2
polkit added MemoryMax= to its service file, which is incompatible with ASan-runs (at least with the current limits)

See the commits for more detailed descriptions.

Also, one note: the santizer job is currently still FUBAR on Fedora Rawhide (or, more specifically, the TEST-50-DISSECT and TEST-58-REPART), because mkfs.erofs also gained a dependency on libudev (through libcurl, see above), but the wrapping currently doesn't work as it also depends on libqpl which is linked with libtsan (which is incompatible with other sanitizers). This is currently tracked in https://bugzilla.redhat.com/show_bug.cgi?id=2461146

github-actions · 2026-04-24T13:13:08Z

bluca · 2026-04-24T13:22:27Z

polkit added MemoryMax= to its service file, which is incompatible with ASan-runs (at least with the current limits)

yeah this is BS, I'll file a revert as it makes no sense

Turns out that the util-linux dep on libsystemd caused more fun than I originally anticipated: $ lddtree /usr/bin/dfuzzer dfuzzer => /usr/bin/dfuzzer (interpreter => /lib64/ld-linux-x86-64.so.2) libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 libz.so.1 => /lib64/libz.so.1 libmount.so.1 => /lib64/libmount.so.1 libblkid.so.1 => /lib64/libblkid.so.1 libsystemd.so.0 => /lib64/libsystemd.so.0 libm.so.6 => /lib64/libm.so.6 ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 libselinux.so.1 => /lib64/libselinux.so.1 libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 ... Also, the tpm2 utils now depend on libudev through libcurl -> libssh -> libfido2 dep chain: $ lddtree /usr/bin/tpm2_pcrread tpm2_pcrread => /usr/bin/tpm2_pcrread (interpreter => /lib64/ld-linux-x86-64.so.2) ... libcurl.so.4 => /lib64/libcurl.so.4 ... libssh.so.4 => /lib64/libssh.so.4 libfido2.so.1 => /lib64/libfido2.so.1 libcbor.so.0.13 => /lib64/libcbor.so.0.13 libudev.so.1 => /lib64/libudev.so.1 libgcc_s.so.1 => /lib64/libgcc_s.so.1 ... Follow-up for 8030e0b.

As the memory usage under sanitizers is quite unpredictable. This is currently relevant mainly for Polkit, as it introduced memory limits for its polkitd.service unit in the latest version [0] which are very easy to trigger when running under sanitizers (as polkitd depends on libsystemd which brings ASan into polkitd's address space). [0] polkit-org/polkit@7d9c06c

LLVM 22 introduced an additional check [0] for ptrace() syscall when invoking sanitizers [0] which currently produces a false-positive warning when running some of our units under sanitizers: [ 47.524680] systemd-timedated[740]: ==740==WARNING: ptrace appears to be blocked (is seccomp enabled?). LeakSanitizer may hang. [ 47.524680] systemd-timedated[740]: ==740==Child exited with signal 15. ... [ 1555.734223] systemd-oomd[93]: ==93==WARNING: ptrace appears to be blocked (is seccomp enabled?). LeakSanitizer may hang. [ 1555.734223] systemd-oomd[93]: ==93==Child exited with signal 15. ... It is a false positive because we disable the seccomp filters system-wide for our units in the sanitizer jobs. Now, from what I've seen so far this happens only in Type=notify(-reload) units that also utilize bus_event_loop_with_idle(). This, combined with the fact that the ptrace()-check child process from [0] checks only if the child process was killed by _any_ signal, means that if the systemd unit exits on its own after becoming idle and then something sends it SIGTERM (either via explicit `systemctl stop` or during system shutdown), this SIGTERM might hit the ptrace()-check child process from the sanitizer handler (as we also send the signal to all processes in the target cgroup), which the parent process then mistakenly evaluates as a blocked ptrace() syscall, even though the check process wasn't killed by SIGSYS. I filed this as [1] to the LLVM project, but let's also temporarily ignore the warning in the sanitizer report processing, as it currently causes annoying test fails. [0] llvm/llvm-project@a708b4b [1] llvm/llvm-project#193714

…aries Let's drop the quarantine that ASan uses for use-after-free detection, as it's pointless in wrapped binaries and can consume up to 256 MiB of memory (with the default configuration). Also, don't keep any stack traces for allocations & deallocations, which should (slightly) help with both memory & performance overhead.

The original find was matching even our test units, which caused issues when the check was extended with Memory*= directives, as we stripped them off from test units for TEST-55-OOMD where we certainly need them. Since the stripping was meant primarily for "production-grade" units, let's limit it to units under /etc/systemd/system/ and /usr/lib/systemd/system/.

mrc0mmand added tests claude-review labels Apr 24, 2026