forked from systemd/systemd
-
Notifications
You must be signed in to change notification settings - Fork 0
build(deps): bump systemd/mkosi from 10 to 12 #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bumps [systemd/mkosi](https://github.com/systemd/mkosi) from 10 to 12. - [Release notes](https://github.com/systemd/mkosi/releases) - [Changelog](https://github.com/systemd/mkosi/blob/main/NEWS.md) - [Commits](systemd/mkosi@4d64fc8...bf884c3) --- updated-dependencies: - dependency-name: systemd/mkosi dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
Author
|
Looks like systemd/mkosi is up-to-date now, so this is no longer needed. |
ssahani
pushed a commit
that referenced
this pull request
Jan 10, 2022
It was reported as used by the linker: > [It is] called in the setup of ld-linux-x86-64.so.2 from _dl_sysdep_start. > My local call stack (with LTO): > > #0 init_cpu_features.constprop.0 (/usr/lib64/ld-linux-x86-64.so.2) > #1 _dl_sysdep_start (/usr/lib64/ld-linux-x86-64.so.2) > #2 _dl_start (/usr/lib64/ld-linux-x86-64.so.2) > #3 _start (/usr/lib64/ld-linux-x86-64.so.2) > > Looking through the source, I think it's this (links for glibc 2.34): > - First dl_platform_init calls _dl_x86_init_cpu_features, a wrapper for init_cpu_features. > - Then init_cpu_features calls get_cet_status. > - At last, get_cet_status invokes arch_prctl. Fixes systemd#22033.
ssahani
pushed a commit
that referenced
this pull request
Jan 31, 2022
by always calling journal_remote_server_destroy, which resets global
variables like journal_remote_server_global. It should prevent crashes like
```
Assertion 'journal_remote_server_global == NULL' failed at src/journal-remote/journal-remote.c:312, function int journal_remote_server_init(RemoteServer *, const char *, JournalWriteSplitMode, _Bool, _Bool)(). Aborting.
AddressSanitizer:DEADLYSIGNAL
=================================================================
==24769==ERROR: AddressSanitizer: ABRT on unknown address 0x0539000060c1 (pc 0x7f23b4d5818b bp 0x7ffcbc4080c0 sp 0x7ffcbc407e70 T0)
SCARINESS: 10 (signal)
#0 0x7f23b4d5818b in raise /build/glibc-eX1tMB/glibc-2.31/sysdeps/unix/sysv/linux/raise.c:51:1
#1 0x7f23b4d37858 in abort /build/glibc-eX1tMB/glibc-2.31/stdlib/abort.c:79:7
#2 0x7f23b5731809 in log_assert_failed systemd/src/basic/log.c:866:9
```
ssahani
pushed a commit
that referenced
this pull request
Jan 31, 2022
Turns out that part of systemd isn't covered by any fuzz targets and
that's not ideal considering that it parses data sent remotely. The
fuzzer triggers an infinite loop in lease_parse_routes as soon as it
starts so it seems to be working :-)
```
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 23620602
INFO: Loaded 2 modules (182073 inline 8-bit counters): 176548 [0x7fdf511fc8d0, 0x7fdf51227a74), 5525 [0x5f6ef0, 0x5f8485),
INFO: Loaded 2 PC tables (182073 PCs): 176548 [0x7fdf51227a78,0x7fdf514d94b8), 5525 [0x5f8488,0x60ddd8),
./build/fuzz-dhcp-client: Running 1 inputs 1 time(s) each.
Running: test/fuzz/fuzz-dhcp-client/timeout-ed34161922c7075c4773f2ada3dee8685d220980
ALARM: working on the last Unit for 31 seconds
and the timeout value is 30 (use -timeout=N to change)
==80731== ERROR: libFuzzer: timeout after 31 seconds
#0 0x51b32e in __sanitizer_print_stack_trace (/home/vagrant/systemd/build/fuzz-dhcp-client+0x51b32e)
#1 0x4689e9 in fuzzer::PrintStackTrace() (/home/vagrant/systemd/build/fuzz-dhcp-client+0x4689e9)
#2 0x44a0f4 in fuzzer::Fuzzer::StaticAlarmCallback() (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a0f4)
#3 0x7fdf4f8b474f (/lib64/libc.so.6+0x4274f)
#4 0x465fee in __sanitizer_cov_trace_const_cmp4 (/home/vagrant/systemd/build/fuzz-dhcp-client+0x465fee)
#5 0x57eee5 in lease_parse_routes /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:495:23
#6 0x57baf3 in dhcp_lease_parse_options /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:701:21
#7 0x572450 in parse_options /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:348:33
#8 0x571cea in dhcp_option_parse /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:381:21
#9 0x559a01 in client_handle_offer /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-client.c:1543:13
#10 0x5592bd in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/libsystemd-network/fuzz-dhcp-client.c:78:9
#11 0x44a379 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a379)
#12 0x42ae1f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x42ae1f)
#13 0x432ade in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x432ade)
#14 0x421f86 in main (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421f86)
#15 0x7fdf4f89f55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
#16 0x7fdf4f89f60b in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
#17 0x421fd4 in _start (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421fd4)
SUMMARY: libFuzzer: timeout
```
ssahani
pushed a commit
that referenced
this pull request
Jan 31, 2022
=================================================================
==81071==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x51245c in __interceptor_reallocarray (/home/vagrant/systemd/build/fuzz-dhcp-client+0x51245c)
#1 0x7f01440c67e6 in strv_push /home/vagrant/systemd/build/../src/basic/strv.c:435:13
#2 0x7f01440ca9e1 in strv_consume /home/vagrant/systemd/build/../src/basic/strv.c:506:13
#3 0x7f01440ca9e1 in strv_extend /home/vagrant/systemd/build/../src/basic/strv.c:558:16
#4 0x5806e3 in dhcp_lease_parse_search_domains /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:900:21
#5 0x57c1be in dhcp_lease_parse_options /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:727:21
#6 0x572450 in parse_options /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:348:33
#7 0x571c6a in dhcp_option_parse /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:376:13
#8 0x559a01 in client_handle_offer /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-client.c:1543:13
#9 0x5592bd in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/libsystemd-network/fuzz-dhcp-client.c:74:16
#10 0x44a379 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a379)
#11 0x42ae1f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x42ae1f)
#12 0x432ade in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x432ade)
#13 0x421f86 in main (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421f86)
#14 0x7f0142fff55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
ssahani
pushed a commit
that referenced
this pull request
Apr 11, 2022
ssahani
pushed a commit
that referenced
this pull request
Apr 11, 2022
ssahani
pushed a commit
that referenced
this pull request
Apr 11, 2022
We can't really use conf_files_list() for finding type #1 entries, since it is case-sensitive, but type #1 entries are typically placed on VFAT, i.e. are case-insensitive. hence, use readdir_all() instead, which is quite similar, but gives us all files, and allows us to do a case-insensitive check. While we are at it, use openat() on the open dir to open the file, and pass that around, to make things a tiny bit more race-free.
ssahani
pushed a commit
that referenced
this pull request
May 11, 2022
```
timedatectl list-timezones --no-pager
...
==164329==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 8192 byte(s) in 1 object(s) allocated from:
#0 0x7fe8a74b6f8c in reallocarray (/lib64/libasan.so.6+0xaef8c)
#1 0x7fe8a63485dc in strv_push ../src/basic/strv.c:419
#2 0x7fe8a6349419 in strv_consume ../src/basic/strv.c:490
#3 0x7fe8a634958d in strv_extend ../src/basic/strv.c:542
#4 0x7fe8a643d787 in bus_message_read_strv_extend ../src/libsystemd/sd-bus/bus-message.c:5606
#5 0x7fe8a643db9d in sd_bus_message_read_strv ../src/libsystemd/sd-bus/bus-message.c:5628
#6 0x4085fb in list_timezones ../src/timedate/timedatectl.c:314
#7 0x7fe8a61ef3e1 in dispatch_verb ../src/shared/verbs.c:103
#8 0x410f91 in timedatectl_main ../src/timedate/timedatectl.c:1025
#9 0x41111c in run ../src/timedate/timedatectl.c:1043
#10 0x411242 in main ../src/timedate/timedatectl.c:1046
#11 0x7fe8a489df1f in __libc_start_call_main (/lib64/libc.so.6+0x40f1f)
```
ssahani
pushed a commit
that referenced
this pull request
May 24, 2022
UEFI provides a "monotonic boot counter" which is supposed to increase on each reboot. We can include this in our random seed hash logic, which makes things more robust in case our changes to the ESP end up not actually being as persistent as we assume. As long as the monotonic boot counter increases we should be good, as each boot we'll anyway end up with a new seed that way. This in fact should also pave the way that we can eventually enable the random seed logic even on SecureBoot enabled systems. Why that? With this change the input for the random seed hash is now: 1. the old seed file contents 2. (optionally) some bits from the UEFI RNG 3. (optionally) a per system random "token" stored in an UEFI variable, initialized at OS install 4. the UEFI monotonic counter 5. a counter integer used by the random seed logic. We can ignore #5 entirely for security considerations, it's always going to be a constant series of values determined by the random seed logic. The #1 file is under control of the attacker. (Since it resides in the unprotected ESP) The #2 data is possibly low quality. (it's hard enough to trust the quality of the Linux RNG, let's not go as far as trusting the UEFI one) The #3 data should not be under control of the attacker, and should only exist if explicitly set. Unless you have privileged access to the system you should not be able to read or set it. (well, within limits of flash chip security and its connectivity to the firmware) The #4 data is provided by the firmware, and should not be under control of the attacker. If it works correctly then it might still be guessable (i.e. a new system might have the counter close to zero). Thus: 1+2+5 are guessable/under control of attacker, but 3+4 should not be. Thus, if 3 is not known to attacker and not guessable, and 4 strictly monotonically increasing then it should be enough to guarantee that every boot will get a different seed passed in, that should not be known or guessable by the attacker. That all said, this patch does not enable the random seed logic on SecureBoot. That is left for a later patch.
ssahani
pushed a commit
that referenced
this pull request
May 30, 2022
We said "`$BOOT/loader/` is the directory containing all files needed for Type #1 entries" which is blatantly wrong. And also saying that we define two directories, /loader and /loader/entries, but only ever defining the second one was not very consistent. Instead, let's say that /loader/ is for "boot loader configuration", and /loader/entries has the snippets. A new section about /<entry-token>/<version>/ is added. This is described as the "recommended layout for additional files". Also, we said that ID= should be used in the file name, but in fact it wasn't in the example that was given, and afaik, nobody ever did that. So this part is reduced to say "kernel version (as returned by `uname -r`, including the OS identifier)". AFAIK, all distros include some form of OS identifier in the version, so this should be good enough. Since we now don't depend on autodetection (e.g. with entry-token and layout configured), the installed doesn't need to always create /loader/entries and things will still work. So don't say that the installer needs to create it. Part of the discussion is moved to the Discussion section. Overall, this brings the specification more in line with actual practice.
ssahani
pushed a commit
that referenced
this pull request
Jun 14, 2022
Provide some coverage for systemd#23481. Without 794da5a: ``` [ 34.730815] testsuite-29.sh[600]: + portablectl detach --now --runtime --enable /tmp/rootdir minimal-app0 Stopping minimal-app0-foo.service... [ OK ] Stopped minimal-app0-foo.service. Stopping minimal-app0.service... [ OK ] Stopped minimal-app0.service. [ 34.878050] testsuite-29.sh[1383]: ================================================================= [ 34.878421] testsuite-29.sh[1383]: ==1383==ERROR: LeakSanitizer: detected memory leaks [ 34.878784] testsuite-29.sh[1383]: Direct leak of 48 byte(s) in 2 object(s) allocated from: [ 34.879174] testsuite-29.sh[1383]: #0 0x7fdf9c8b0f8c in reallocarray (/lib64/libasan.so.6+0xaef8c) [ 34.879554] testsuite-29.sh[1383]: #1 0x7fdf9b4270f5 in unit_file_changes_add ../src/shared/install.c:282 [ 34.879926] testsuite-29.sh[1383]: #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688 [ 34.880267] testsuite-29.sh[1383]: #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582 [ 34.880673] testsuite-29.sh[1383]: #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810 [ 34.881064] testsuite-29.sh[1383]: #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924 [ 34.881493] testsuite-29.sh[1383]: #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103 [ 34.881953] testsuite-29.sh[1383]: #7 0x41604a in run ../src/portable/portablectl.c:1427 [ 34.882459] testsuite-29.sh[1383]: #8 0x416106 in main ../src/portable/portablectl.c:1430 [ 34.882947] testsuite-29.sh[1383]: #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f) [ 34.883368] testsuite-29.sh[1383]: Indirect leak of 104 byte(s) in 2 object(s) allocated from: [ 34.883732] testsuite-29.sh[1383]: #0 0x7fdf9c85b8f7 in strdup (/lib64/libasan.so.6+0x598f7) [ 34.884089] testsuite-29.sh[1383]: #1 0x7fdf9b4271aa in unit_file_changes_add ../src/shared/install.c:288 [ 34.884508] testsuite-29.sh[1383]: #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688 [ 34.884926] testsuite-29.sh[1383]: #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582 [ 34.885307] testsuite-29.sh[1383]: #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810 [ 34.885647] testsuite-29.sh[1383]: #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924 [ 34.885987] testsuite-29.sh[1383]: #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103 [ 34.886271] testsuite-29.sh[1383]: #7 0x41604a in run ../src/portable/portablectl.c:1427 [ 34.886557] testsuite-29.sh[1383]: #8 0x416106 in main ../src/portable/portablectl.c:1430 [ 34.886892] testsuite-29.sh[1383]: #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f) [ 34.887187] testsuite-29.sh[1383]: Indirect leak of 2 byte(s) in 2 object(s) allocated from: [ 34.887520] testsuite-29.sh[1383]: #0 0x7fdf9c85b8f7 in strdup (/lib64/libasan.so.6+0x598f7) [ 34.887797] testsuite-29.sh[1383]: #1 0x7fdf9b427249 in unit_file_changes_add ../src/shared/install.c:296 [ 34.888117] testsuite-29.sh[1383]: #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688 [ 34.888434] testsuite-29.sh[1383]: #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582 [ 34.888693] testsuite-29.sh[1383]: #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810 [ 34.888990] testsuite-29.sh[1383]: #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924 [ 34.889254] testsuite-29.sh[1383]: #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103 [ 34.889580] testsuite-29.sh[1383]: #7 0x41604a in run ../src/portable/portablectl.c:1427 [ 34.889877] testsuite-29.sh[1383]: #8 0x416106 in main ../src/portable/portablectl.c:1430 [ 34.890193] testsuite-29.sh[1383]: #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f) [ 34.890482] testsuite-29.sh[1383]: SUMMARY: AddressSanitizer: 154 byte(s) leaked in 6 allocation(s). ``` With 794da5a: ``` [ OK ] Started minimal-app0.service. [ 36.794367] testsuite-29.sh[600]: + portablectl detach --now --runtime --enable /tmp/rootdir minimal-app0 Stopping minimal-app0-foo.service... [ OK ] Stopped minimal-app0-foo.service. Stopping minimal-app0.service... [ OK ] Stopped minimal-app0.service. [ 36.851251] testsuite-29.sh[600]: + umount /tmp/rootdir ```
ssahani
pushed a commit
that referenced
this pull request
Jun 17, 2022
Fixes: CID#1469711 CID 1469711 (#1 of 1): Uninitialized scalar variable (UNINIT) 14. uninit_use: Using uninitialized value we_detached.
ssahani
pushed a commit
that referenced
this pull request
Aug 16, 2022
Report whether the devicetree + sort-key boot loader spec type #1 fields are supported, and whether the "@saved" pseudo-entry is supported. Strictly speaking, thes features have been added in versions that are already released (250+), so by adding this those version even though they support the features will be considered not supporting them, but that should be OK (the opposite would be a problem though, i.e. if we'd assume a boot loader had a feature it actually does not). These three features are features relevant to userspace, as it allows userspace to tweak/genereate BLS entries or set EFI vars correctly. Other features (i.e. that have no impliciations to userspace) are not reported.
ssahani
pushed a commit
that referenced
this pull request
Sep 5, 2022
Inspired by systemd#23913, let's complain if people use paths with ".." in Type #1 bootspec entries. Let's prefix all paths with "/" if it is missing. Let's simplify all paths. let's refuse paths/warn with "..". Fixes: systemd#23913
ssahani
pushed a commit
that referenced
this pull request
Sep 5, 2022
This is a workaround for an issue in the memory sanitizer.
If a function is called with too many arguments, then the sanitizer
triggers the following false-positive warning:
==349==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f8b247134a7 in json_buildv /work/build/../../src/systemd/src/shared/json.c:3213:17
#1 0x7f8b24714231 in json_build /work/build/../../src/systemd/src/shared/json.c:4117:13
#2 0x7f8b24487fa5 in show_boot_entries /work/build/../../src/systemd/src/shared/bootspec.c:1424:29
#3 0x4a6a1b in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-bootspec.c:119:16
#4 0x4c6693 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#5 0x4c5e7a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
#6 0x4c7ce4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:826:7
#7 0x4c7f19 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:857:3
#8 0x4b757f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
#9 0x4e0bd2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#10 0x7f8b23ead082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
#11 0x41f69d in _start (build-out/fuzz-bootspec+0x41f69d)
Follow-up for systemd#24541.
Fixes systemd#24551.
ssahani
pushed a commit
that referenced
this pull request
Oct 12, 2022
We would print the whole thing in extenso. Users generally don't care,
and would likely prefer to just get the compact identifier of the package
that they can use in a bug report or package manager commands.
Before:
systemd-coredump[40645]: [🡕] Process 1975 (gnome-shell) of user 1000 dumped core.
Module /usr/bin/gnome-shell (deleted) with build-id aafdb7d69a7efca937e490080ad9348541fc57d8
Metadata for module /usr/bin/gnome-shell (deleted) owned by FDO found: {
"type" : "rpm",
"name" : "gnome-shell",
"version" : "43~rc-3.fc37",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
Module /usr/lib64/gnome-shell/libgvc.so (deleted) with build-id 56cbb9862e1ee84ca1549b94f2b4cda03537613e
Metadata for module /usr/lib64/gnome-shell/libgvc.so (deleted) owned by FDO found: {
"type" : "rpm",
"name" : "gnome-shell",
"version" : "43~rc-2.fc37",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
Module /usr/lib64/libLLVM-14.so (deleted) with build-id ffa7e43f48eb4c189304c0241b1862710de4c3a4
Metadata for module /usr/lib64/libLLVM-14.so (deleted) owned by FDO found: {
"type" : "rpm",
"name" : "gnome-shell",
"version" : "43~rc-2.fc37",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
After:
systemd-coredump[235218]: [🡕] Process 235216 (bash) of user 1000 dumped core.
Module libtinfo.so.6 from rpm ncurses-6.3-3.20220501.fc37.x86_64, build-id=71a04d23fd572525eb6efc47026c379725e06d96
Module bash from rpm bash-5.1.16-3.fc37.x86_64, build-id=6c936aff95a2ccda04a3fb685a81a84a0a8d10da
Stack trace of thread 235216:
#0 0x00007fa409ec8d8b kill (libc.so.6 + 0x38d8b)
#1 0x0000560d35e366b1 kill_builtin (bash + 0xad6b1)
#2 0x0000560d35dd7227 execute_builtin.lto_priv.0 (bash + 0x4e227)
#3 0x0000560d35dd0459 execute_simple_command (bash + 0x47459)
#4 0x0000560d35dd1de0 execute_command_internal (bash + 0x48de0)
#5 0x0000560d35e307aa parse_and_execute (bash + 0xa77aa)
#6 0x0000560d35e91b08 run_one_command.isra.0 (bash + 0x108b08)
#7 0x0000560d35dba07c main (bash + 0x3107c)
#8 0x00007fa409eb3510 __libc_start_call_main (libc.so.6 + 0x23510)
#9 0x00007fa409eb35c9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x235c9)
#10 0x0000560d35dbad85 _start (bash + 0x31d85)
ssahani
pushed a commit
that referenced
this pull request
Oct 18, 2022
This wrapper is used in situations where we don't care about *San reports,
we just want to make things work. However, with enabled LSan we might
trigger some bogus reports we're definitely not interested in, causing
unexpected test fails.
Spotted on C8S in TEST-34-DYNAMICUSERMIGRATE:
```
[10654.804162] testsuite-34.sh[56]: + systemctl start testservice-34-check-writable.service
Starting testservice-34-check-writable.service...
[10655.055969] bash[546]: + set -o pipefail
[10655.056127] bash[546]: + declare -a writable_dirs
[10655.056234] bash[546]: + readarray -t writable_dirs
[10655.060838] bash[548]: ++ find / '(' -path /var/tmp -o -path /tmp -o -path /proc -o -path /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf -o -path /dev/.lxc -o -path /sys/devices/system/cpu ')' -prune -o -type d -writable -print
[10655.061534] bash[549]: ++ sort -u
[10655.688740] bash[547]: =================================================================
[10655.689075] bash[547]: ==547==ERROR: LeakSanitizer: detected memory leaks
[10655.689246] bash[547]: Direct leak of 112 byte(s) in 1 object(s) allocated from:
[10655.743851] bash[547]: #0 0x7ffff752d364 (/usr/lib64/clang/14.0.0/lib/libclang_rt.asan-powerpc64le.so+0x13d364) (BuildId: 321f4ed1caea6a1a4c37f9272e07275cf16f034d)
[10655.744060] bash[547]: #1 0x1000b5d20 in xmalloc (/usr/bin/bash+0xb5d20) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744224] bash[547]: #2 0x100083338 (/usr/bin/bash+0x83338) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744393] bash[547]: #3 0x10008847c (/usr/bin/bash+0x8847c) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744552] bash[547]: #4 0x1000af6ec in redirection_expand (/usr/bin/bash+0xaf6ec) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744728] bash[547]: #5 0x1000b005c (/usr/bin/bash+0xb005c) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744886] bash[547]: #6 0x1000b1388 in do_redirections (/usr/bin/bash+0xb1388) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745051] bash[547]: #7 0x100050484 (/usr/bin/bash+0x50484) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745208] bash[547]: #8 0x100052160 in execute_command_internal (/usr/bin/bash+0x52160) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745376] bash[547]: #9 0x100052a10 in execute_command_internal (/usr/bin/bash+0x52a10) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745536] bash[547]: #10 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745711] bash[547]: #11 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745870] bash[547]: #12 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746038] bash[547]: #13 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746198] bash[547]: #14 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746367] bash[547]: #15 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746548] bash[547]: #16 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746741] bash[547]: #17 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746897] bash[547]: #18 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747067] bash[547]: #19 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747227] bash[547]: #20 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747414] bash[547]: #21 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747573] bash[547]: #22 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747741] bash[547]: #23 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747896] bash[547]: #24 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748064] bash[547]: #25 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748225] bash[547]: #26 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748390] bash[547]: #27 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748553] bash[547]: #28 0x1000bf91c in parse_and_execute (/usr/bin/bash+0xbf91c) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748717] bash[547]: #29 0x1000311ec (/usr/bin/bash+0x311ec) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748883] bash[547]: Direct leak of 17 byte(s) in 1 object(s) allocated from:
...
```
ssahani
pushed a commit
that referenced
this pull request
Nov 4, 2022
The test would fail when addresses were being removed in parallel. In general, the check is only valid when the machine configuration is static, which in general isn't true. CentOS CI (Arch Linux) fails in TEST-02-UNITTESTS test-local-addresses: 10:38:05 (gdb) #0 0x00007f86260a164c in ?? () from /usr/lib/libc.so.6 10:38:05 No symbol table info available. 10:38:05 #1 0x00007f8626051958 in raise () from /usr/lib/libc.so.6 10:38:05 No symbol table info available. 10:38:05 #2 0x00007f862603b53d in abort () from /usr/lib/libc.so.6 10:38:05 No symbol table info available. 10:38:05 #3 0x00007f862639a755 in log_assert_failed ( 10:38:05 text=text@entry=0x56180e56c03b "n == n_ipv4 + n_ipv6", 10:38:05 file=file@entry=0x56180e56c0d1 "src/test/test-local-addresses.c", 10:38:05 line=line@entry=45, 10:38:05 func=func@entry=0x56180e56c360 <__PRETTY_FUNCTION__.6> "test_local_addresses") at ../build/src/basic/log.c:853 10:38:05 No locals. 10:38:05 #4 0x000056180e56b77e in test_local_addresses () 10:38:05 at ../build/src/test/test-local-addresses.c:45 10:38:05 a = 0x0 10:38:05 n = 234 10:38:05 n_ipv4 = 236 10:38:05 n_ipv6 = 7 10:38:05 __PRETTY_FUNCTION__ = "test_local_addresses" 10:38:05 __func__ = "test_local_addresses" 10:38:05 #5 0x000056180e56ba67 in run_test_table () at ../build/src/shared/tests.h:106 10:38:05 r = 0 10:38:05 t = 0x56180e56e010 <__unique_prefix_static_test_table_entry10> 10:38:05 __PRETTY_FUNCTION__ = <optimized out> 10:38:05 __func__ = "run_test_table" 10:38:05 #6 0x000056180e56bb2f in main (argc=1, argv=0x7ffc3a814808) 10:38:05 at ../build/src/test/test-local-addresses.c:81 10:38:05 _intro = 0x0 10:38:05 _outro = 0x0 10:38:05 _r = 0 10:38:05 _q = 0 10:38:05 (gdb) The logs show that there's a huge number of private addresses, probably from some other test running in parallel.
ssahani
pushed a commit
that referenced
this pull request
Nov 4, 2022
…ocale= \#0 __strcmp_evex () at ../sysdeps/x86_64/multiarch/strcmp-evex.S:295 No locals. \#1 0x0000557444eb172b in process_locale () at ../src/firstboot/firstboot.c:342 etc_localeconf = 0x7ffd40217b80 "/root/root/etc/locale.conf" locales = {0x0, 0x0, 0x0} i = 0 r = <optimized out> __PRETTY_FUNCTION__ = "process_locale" __func__ = "process_locale" \#2 0x0000557444eaff93 in run (argv=0x7ffd40217d98, argc=3) at ../src/firstboot/firstboot.c:1401 loop_device = 0x0 unlink_dir = 0x0 r = <optimized out> loop_device = <optimized out> unlink_dir = <optimized out> r = <optimized out> __func__ = <optimized out> __PRETTY_FUNCTION__ = <optimized out> enabled = <optimized out> _error = <optimized out> _level = <optimized out> _e = <optimized out> _level = <optimized out> _e = <optimized out> \#3 main (argc=3, argv=0x7ffd40217d98) at ../src/firstboot/firstboot.c:1432 r = <optimized out> __PRETTY_FUNCTION__ = "main" Fixes systemd#25249
ssahani
pushed a commit
that referenced
this pull request
Nov 29, 2022
Currently the kernel-install man page only documents the bls layout for use with the boot loader spec type #1. 90-loaderentry.install uses this layout to generate loader entries and copy the kernel image and initrd to $BOOT. This commit documents a second layout "uki" and adds 90-uki-copy.install, which copies a UKI "uki.efi" from the staging area or any file with the .efi extension given on the command line to $BOOT/EFI/Linux/$ENTRY_TOKEN-$KERNEl_VERSION(+$TRIES).efi This allows for both locally generated and distro-provided UKIs to be handled by kernel-install.
ssahani
pushed a commit
that referenced
this pull request
Dec 5, 2022
```
../src/basic/hexdecoct.c:66:44: runtime error: applying zero offset to null pointer
#0 0x7f6022650c44 in hexmem /home/vagrant/systemd/build-fuzzers/../src/basic/hexdecoct.c:66:44
#1 0x577583 in dns_resource_record_to_string /home/vagrant/systemd/build-fuzzers/../src/resolve/resolved-dns-rr.c:1140:21
#2 0x563669 in LLVMFuzzerTestOneInput /home/vagrant/systemd/build-fuzzers/../src/resolve/fuzz-resource-record.c:25:39
#3 0x44d2a1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-resource-record+0x44d2a1) (BuildId: 88135c111396e9441a475302ccabd2f9a58c7e89)
#4 0x42d32f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-resource-record+0x42d32f) (BuildId: 88135c111396e9441a475302ccabd2f9a58c7e89)
#5 0x434920 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/out/fuzz-resource-record+0x434920) (BuildId: 88135c111396e9441a475302ccabd2f9a58c7e89)
#6 0x424006 in main (/home/vagrant/systemd/out/fuzz-resource-record+0x424006) (BuildId: 88135c111396e9441a475302ccabd2f9a58c7e89)
#7 0x7f602142950f in __libc_start_call_main (/lib64/libc.so.6+0x2950f) (BuildId: 85c438f4ff93e21675ff174371c9c583dca00b2c)
#8 0x7f60214295c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x295c8) (BuildId: 85c438f4ff93e21675ff174371c9c583dca00b2c)
#9 0x424044 in _start (/home/vagrant/systemd/out/fuzz-resource-record+0x424044) (BuildId: 88135c111396e9441a475302ccabd2f9a58c7e89)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/basic/hexdecoct.c:66:44 in
```
ssahani
pushed a commit
that referenced
this pull request
Feb 9, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
ssahani
pushed a commit
that referenced
this pull request
May 30, 2023
==8036==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x4a10bc in __interceptor_realloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:85:3
#1 0x4deef1 in realloc (/build/fuzz-unit-file+0x4deef1)
#2 0x7ffa35abfe23 in greedy_realloc /work/build/../../src/systemd/src/basic/alloc-util.c:70:13
#3 0x7ffa35aefad2 in parse_env_file_internal /work/build/../../src/systemd/src/basic/env-file.c:127:38
#4 0x7ffa35af08a6 in parse_env_file_fdv /work/build/../../src/systemd/src/basic/env-file.c:374:13
#5 0x7ffa35b6391e in parse_extension_release_atv /work/build/../../src/systemd/src/basic/os-util.c:323:16
#6 0x7ffa35b63c8a in parse_extension_release_sentinel /work/build/../../src/systemd/src/basic/os-util.c:360:13
#7 0x7ffa35a5e3f5 in parse_os_release_specifier /work/build/../../src/systemd/src/shared/specifier.c:292:13
#8 0x7ffa35a5e3f5 in specifier_os_id /work/build/../../src/systemd/src/shared/specifier.c:303:16
#9 0x7ffa35a5c7f5 in specifier_printf /work/build/../../src/systemd/src/shared/specifier.c:70:45
#10 0x7ffa3690b279 in unit_full_printf_full /work/build/../../src/systemd/src/core/unit-printf.c:264:16
#11 0x7ffa367de795 in config_parse_bus_name /work/build/../../src/systemd/src/core/load-fragment.c:2401:13
#12 0x7ffa358fe5ec in next_assignment /work/build/../../src/systemd/src/shared/conf-parser.c:151:24
#13 0x7ffa358fe5ec in parse_line /work/build/../../src/systemd/src/shared/conf-parser.c:257:16
#14 0x7ffa358fd653 in config_parse /work/build/../../src/systemd/src/shared/conf-parser.c:400:21
#15 0x4de828 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/core/fuzz-unit-file.c:72:16
#16 0x4df208 in NaloFuzzerTestOneInput (/build/fuzz-unit-file+0x4df208)
#17 0x4fe213 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#18 0x4fd9fa in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
#19 0x4ff0c9 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
#20 0x4ffd95 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
#21 0x4ef0ff in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
#22 0x4ef9c8 in LLVMFuzzerRunDriver /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:925:10
#23 0x4df485 in main (/build/fuzz-unit-file+0x4df485)
#24 0x7ffa35232082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
DEDUP_TOKEN: __interceptor_realloc--realloc--greedy_realloc
SUMMARY: AddressSanitizer: 64 byte(s) leaked in 1 allocation(s).
Found by Nallocfuzz.
ssahani
pushed a commit
that referenced
this pull request
May 30, 2023
Otherwise we might hit an assertion during cleanup if the
following mmap_cache_new() call fails:
Assertion 'p->n_ref > 0' failed at src/journal-remote/journal-remote-write.c:80, function writer_unref(). Aborting.
==2069==ERROR: AddressSanitizer: ABRT on unknown address 0x000000000815 (pc 0x7f39dcd0200b bp 0x7ffe2fe24db0 sp 0x7ffe2fe24b60 T0)
SCARINESS: 10 (signal)
#0 0x7f39dcd0200b in raise (/lib/x86_64-linux-gnu/libc.so.6+0x4300b) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
#1 0x7f39dcce1858 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x22858) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x7f39dd747e49 in log_assert_failed /work/build/../../src/systemd/src/basic/log.c:940:9
#3 0x4e4431 in writer_unref /work/build/../../src/systemd/src/journal-remote/journal-remote-write.c:80:1
#4 0x4e3fd5 in writer_unrefp /work/build/../../src/systemd/src/journal-remote/journal-remote-write.h:27:1
#5 0x4e3fd5 in writer_new /work/build/../../src/systemd/src/journal-remote/journal-remote-write.c:56:1
#6 0x4e04bc in journal_remote_get_writer /work/build/../../src/systemd/src/journal-remote/journal-remote.c:125:21
#7 0x4e0e0b in get_source_for_fd /work/build/../../src/systemd/src/journal-remote/journal-remote.c:181:13
#8 0x4e0e0b in journal_remote_add_source /work/build/../../src/systemd/src/journal-remote/journal-remote.c:233:13
#9 0x4df99f in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/journal-remote/fuzz-journal-remote.c:54:9
#10 0x4e8f48 in NaloFuzzerTestOneInput (/build/fuzz-journal-remote+0x4e8f48)
#11 0x507f53 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#12 0x50773a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
#13 0x508e09 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
#14 0x509ad5 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
#15 0x4f8e3f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
#16 0x4f9708 in LLVMFuzzerRunDriver /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:925:10
#17 0x4e91c5 in main (/build/fuzz-journal-remote+0x4e91c5)
#18 0x7f39dcce3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
#19 0x420bcd in _start (/build/fuzz-journal-remote+0x420bcd)
DEDUP_TOKEN: raise--abort--log_assert_failed
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: ABRT (/lib/x86_64-linux-gnu/libc.so.6+0x4300b) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee) in raise
Found by Nallocufzz.
ssahani
pushed a commit
that referenced
this pull request
May 30, 2023
If we fail any allocation prior adding the lease to the server lease
hashmap.
==2103==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 128 byte(s) in 2 object(s) allocated from:
#0 0x4a203e in __interceptor_calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:77:3
#1 0x4f6341 in calloc (/build/fuzz-dhcp-server+0x4f6341)
#2 0x4ec818 in add_lease /work/build/../../src/systemd/src/libsystemd-network/fuzz-dhcp-server.c:26:9
#3 0x4ec2bf in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/libsystemd-network/fuzz-dhcp-server.c:75:9
#4 0x4f68a8 in NaloFuzzerTestOneInput (/build/fuzz-dhcp-server+0x4f68a8)
#5 0x5158b3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#6 0x51509a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
#7 0x516769 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
#8 0x517435 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
#9 0x50679f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
#10 0x507068 in LLVMFuzzerRunDriver /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:925:10
#11 0x4f6b25 in main (/build/fuzz-dhcp-server+0x4f6b25)
#12 0x7f16084e3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
DEDUP_TOKEN: __interceptor_calloc--calloc--add_lease
SUMMARY: AddressSanitizer: 128 byte(s) leaked in 2 allocation(s).
Found by Nallocufzz.
ssahani
pushed a commit
that referenced
this pull request
Jun 6, 2023
==1==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 17 byte(s) in 1 object(s) allocated from:
#0 0x7fc096c7243b in strdup (/lib64/libasan.so.8+0x7243b)
#1 0x7fc095db3899 in bus_socket_set_transient_property ../src/core/dbus-socket.c:386
#2 0x7fc095db5140 in bus_socket_set_property ../src/core/dbus-socket.c:460
#3 0x7fc095dd20f1 in bus_unit_set_properties ../src/core/dbus-unit.c:2473
#4 0x7fc095d87d53 in transient_unit_from_message ../src/core/dbus-manager.c:1025
#5 0x7fc095d8872f in method_start_transient_unit ../src/core/dbus-manager.c:1112
#6 0x7fc0944ddf4f in method_callbacks_run ../src/libsystemd/sd-bus/bus-objects.c:406
#7 0x7fc0944e7854 in object_find_and_run ../src/libsystemd/sd-bus/bus-objects.c:1319
#8 0x7fc0944e8f03 in bus_process_object ../src/libsystemd/sd-bus/bus-objects.c:1439
#9 0x7fc09454ad78 in process_message ../src/libsystemd/sd-bus/sd-bus.c:3011
#10 0x7fc09454b302 in process_running ../src/libsystemd/sd-bus/sd-bus.c:3053
#11 0x7fc09454e158 in bus_process_internal ../src/libsystemd/sd-bus/sd-bus.c:3273
#12 0x7fc09454e2f2 in sd_bus_process ../src/libsystemd/sd-bus/sd-bus.c:3300
#13 0x7fc094551a59 in io_callback ../src/libsystemd/sd-bus/sd-bus.c:3642
#14 0x7fc094727830 in source_dispatch ../src/libsystemd/sd-event/sd-event.c:4187
#15 0x7fc094731009 in sd_event_dispatch ../src/libsystemd/sd-event/sd-event.c:4808
#16 0x7fc094732124 in sd_event_run ../src/libsystemd/sd-event/sd-event.c:4869
#17 0x7fc095f7af9f in manager_loop ../src/core/manager.c:3242
#18 0x41cc7c in invoke_main_loop ../src/core/main.c:1937
#19 0x4252e0 in main ../src/core/main.c:3072
#20 0x7fc092a4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
SUMMARY: AddressSanitizer: 17 byte(s) leaked in 1 allocation(s).
ssahani
pushed a commit
that referenced
this pull request
Jun 6, 2023
On faster machines we might be too fast and kill the fake binary during fork() which then makes kernel report a "wrong" binary in the coredump, e.g.: [ 31.408078] testsuite-74.sh[548]: + /tmp/make-dump /tmp/test-dump SIGTRAP [ 31.409720] testsuite-74.sh[560]: + bin=/tmp/test-dump [ 31.409720] testsuite-74.sh[560]: + sig=SIGTRAP [ 31.409720] testsuite-74.sh[560]: + ulimit -c unlimited [ 31.409720] testsuite-74.sh[560]: + pid=561 [ 31.409720] testsuite-74.sh[560]: + sleep 1 [ 31.409720] testsuite-74.sh[560]: + kill -s SIGTRAP 561 [ 31.409720] testsuite-74.sh[560]: + wait 561 [ 31.491757] systemd[1]: Created slice system-systemd\x2dcoredump.slice. [ 31.524488] systemd[1]: Started [email protected]. [ 31.616372] systemd-coredump[564]: [🡕] Process 561 (make-dump) of user 0 dumped core. Stack trace of thread 561: #0 0x00007ff86bb49af7 _Fork (libc.so.6 + 0xd4af7) #1 0x00007ff86bb4965f __libc_fork (libc.so.6 + 0xd465f) #2 0x000055e88011b0ad make_child (bash + 0x550ad) #3 0x000055e8800fd05f n/a (bash + 0x3705f) #4 0x000055e880100116 execute_command_internal (bash + 0x3a116) #5 0x000055e8801011f2 execute_command_internal (bash + 0x3b1f2) #6 0x000055e8801025b6 execute_command (bash + 0x3c5b6) #7 0x000055e8800f134b reader_loop (bash + 0x2b34b) #8 0x000055e8800e757d main (bash + 0x2157d) #9 0x00007ff86ba98850 n/a (libc.so.6 + 0x23850) #10 0x00007ff86ba9890a __libc_start_main (libc.so.6 + 0x2390a) #11 0x000055e8800e83b5 _start (bash + 0x223b5) ELF object binary architecture: AMD x86-64 [ 31.666617] testsuite-74.sh[560]: /tmp/make-dump: line 12: 561 Trace/breakpoint trap (core dumped) "$bin" infinity ... $ coredumpctl list --file system.journal TIME PID UID GID SIG COREFILE EXE SIZE Fri 2023-06-02 10:42:10 CEST 561 0 0 SIGTRAP journal /usr/bin/bash - Fri 2023-06-02 10:42:11 CEST 570 0 0 SIGABRT journal /tmp/test-dump - Fri 2023-06-02 10:42:12 CEST 582 0 0 SIGTRAP missing /tmp/test-dump - Fri 2023-06-02 10:42:13 CEST 593 0 0 SIGABRT missing /tmp/test-dump -
ssahani
pushed a commit
that referenced
this pull request
Jun 6, 2023
When the header= option comes before any other type= defining one, we trip over an assertion: Jun 04 15:45:33 H testsuite-24.sh[752]: + systemctl start [email protected] Jun 04 15:45:33 H systemd[1]: Starting [email protected]... Jun 04 15:45:33 H systemd-cryptsetup[4641]: Assertion 'name' failed at src/basic/strv.c:21, function strv_find(). Aborting. ... Jun 04 15:45:33 H systemd-coredump[4643]: Process 4641 (systemd-cryptse) of user 0 dumped core. ... Stack trace of thread 4641: #0 0x00007ff9256afe5c __pthread_kill_implementation (libc.so.6 + 0x8ce5c) #1 0x00007ff92565fa76 raise (libc.so.6 + 0x3ca76) #2 0x00007ff9256497fc abort (libc.so.6 + 0x267fc) #3 0x00007ff926076047 log_assert_failed (libsystemd-shared-253.so + 0x276047) #4 0x00007ff9260ab317 strv_find (libsystemd-shared-253.so + 0x2ab317) #5 0x0000000000405927 parse_one_option (systemd-cryptsetup + 0x5927) #6 0x0000000000407793 parse_options (systemd-cryptsetup + 0x7793) #7 0x000000000040fa0c run (systemd-cryptsetup + 0xfa0c) #8 0x000000000041137f main (systemd-cryptsetup + 0x1137f) #9 0x00007ff92564a510 __libc_start_call_main (libc.so.6 + 0x27510) #10 0x00007ff92564a5c9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x275c9) #11 0x0000000000403915 _start (systemd-cryptsetup + 0x3915) ELF object binary architecture: AMD x86-64
ssahani
pushed a commit
that referenced
this pull request
Jun 27, 2023
Provides coverage for systemd#26872. With systemd#26875 reverted: [16444.287652] testsuite-03.sh[71]: + for i in {0..19} [16444.287652] testsuite-03.sh[71]: + systemctl start transaction-cycle0.service [16444.359503] systemd[1]: ================================================================= [16444.360321] systemd[1]: ==1==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6180002e578e at pc 0x7f73b25ec7a6 bp 0x7ffc5531c6f0 sp 0x7ffc5531be68 [16444.360798] systemd[1]: [16444.361044] systemd[1]: READ of size 783 at 0x6180002e578e thread T0 (systemd) [16444.391684] systemd[1]: #0 0x7f73b25ec7a5 (/lib64/libasan.so.5+0x557a5) [16444.392167] systemd[1]: #1 0x7f73b260a1d5 in __interceptor_vasprintf (/lib64/libasan.so.5+0x731d5) [16444.392442] systemd[1]: #2 0x7f73afa1d1e1 in log_format_iovec ../src/basic/log.c:996 [16444.392750] systemd[1]: #3 0x7f73afa1e7b6 in log_struct_internal ../src/basic/log.c:1058 [16444.393101] systemd[1]: #4 0x7f73b1979136 in transaction_verify_order_one ../src/core/transaction.c:392 [16444.393540] systemd[1]: #5 0x7f73b197ac82 in transaction_verify_order_one ../src/core/transaction.c:463 [16444.393946] systemd[1]: #6 0x7f73b197ac82 in transaction_verify_order_one ../src/core/transaction.c:463 [16444.394262] systemd[1]: #7 0x7f73b197ac82 in transaction_verify_order_one ../src/core/transaction.c:463 [16444.394532] systemd[1]: #8 0x7f73b197ac82 in transaction_verify_order_one ../src/core/transaction.c:463 [16444.394812] systemd[1]: #9 0x7f73b197ac82 in transaction_verify_order_one ../src/core/transaction.c:463 ...
ssahani
pushed a commit
that referenced
this pull request
Jun 30, 2023
So we're able to detect memory leaks in our NSS modules. An example after introducing a memory leak in nss-myhostname.c: testsuite-71.sh[2881]: ================================================================= testsuite-71.sh[2881]: ==2880==ERROR: LeakSanitizer: detected memory leaks testsuite-71.sh[2881]: Direct leak of 2 byte(s) in 1 object(s) allocated from: testsuite-71.sh[2881]: #0 0x7fa28907243b in strdup (/usr/lib64/libasan.so.8.0.0+0x7243b) testsuite-71.sh[2881]: #1 0x7fa286a7bc10 in gethostname_full ../src/basic/hostname-util.c:67 testsuite-71.sh[2881]: #2 0x7fa286a74af9 in gethostname_malloc ../src/basic/hostname-util.h:24 testsuite-71.sh[2881]: #3 0x7fa286a756f4 in _nss_myhostname_gethostbyname4_r ../src/nss-myhostname/nss-myhostname.c:79 testsuite-71.sh[2881]: #4 0x7fa288f17588 in getaddrinfo (/lib64/libc.so.6+0xf4588) testsuite-71.sh[2881]: #5 0x7fa2890a4d93 in __interceptor_getaddrinfo.part.0 (/usr/lib64/libasan.so.8.0.0+0xa4d93) testsuite-71.sh[2881]: #6 0x55a54b2b7159 in ahosts_keys_int.part.0 (/usr/bin/getent.orig+0x4159) testsuite-71.sh[2881]: SUMMARY: AddressSanitizer: 2 byte(s) leaked in 1 allocation(s).
ssahani
pushed a commit
that referenced
this pull request
Jul 28, 2023
Spotted while fuzzing systemd#27890. ================================================================= ==908098==ERROR: LeakSanitizer: detected memory leaks Direct leak of 64 byte(s) in 1 object(s) allocated from: #0 0x7f4efe6d81f5 in __interceptor_realloc.part.0 (/lib64/libasan.so.8+0xd81f5) (BuildId: dc689b05ca2577037af24700212bb5cce1f91c8a) #1 0x7f4efb8e3ace in greedy_realloc ../src/basic/alloc-util.c:70 #2 0x7f4efb93b713 in extract_first_word ../src/basic/extract-word.c:62 #3 0x7f4efb970d50 in set_put_strsplit ../src/basic/hashmap.c:1902 #4 0x7f4efd76c27e in exec_context_deserialize ../src/core/execute-serialize.c:3341 #5 0x7f4efd778dcb in exec_deserialize ../src/core/execute-serialize.c:4122 #6 0x4032c0 in LLVMFuzzerTestOneInput ../src/core/fuzz-execute-serialize.c:60 #7 0x403c58 in main ../src/fuzz/fuzz-main.c:50 #8 0x7f4efecccb49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) #9 0x7f4efecccc0a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) #10 0x402344 in _start (/home/mrc0mmand/repos/@systemd/systemd/build-san/fuzz-execute-serialize+0x402344) (BuildId: 195f382cf1e39b9ba48d6dcf5a90f786d72837a8) SUMMARY: AddressSanitizer: 64 byte(s) leaked in 1 allocation(s). Aborted (core dumped) ==911550==ERROR: LeakSanitizer: detected memory leaks Direct leak of 17 byte(s) in 1 object(s) allocated from: #0 0x4df281 in strdup (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x4df281) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6) #1 0x7fe4ae2b38fc in _set_put_strndup_full /home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/../src/basic/hashmap.c:1868:21 #2 0x7fe4b0bad897 in exec_context_deserialize /home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/../src/core/execute-serialize.c:3914:29 #3 0x7fe4b0b80592 in exec_deserialize /home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/../src/core/execute-serialize.c:4109:13 #4 0x531d0f in LLVMFuzzerTestOneInput /home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/../src/core/fuzz-execute-serialize.c:59:16 #5 0x440594 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x440594) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6) #6 0x43f9b9 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x43f9b9) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6) #7 0x440fd5 in fuzzer::Fuzzer::MutateAndTestOne() (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x440fd5) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6) #8 0x441955 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, std::allocator<fuzzer::SizedFile>>&) (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x441955) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6) #9 0x42e151 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x42e151) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6) #10 0x45a916 in main (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x45a916) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6) #11 0x7fe4ac449b49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) #12 0x7fe4ac449c0a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) #13 0x422b74 in _start (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x422b74) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6) SUMMARY: AddressSanitizer: 17 byte(s) leaked in 1 allocation(s).
ssahani
pushed a commit
that referenced
this pull request
Aug 22, 2023
Introduced by 41712cd. ================================================================= ==2194==ERROR: LeakSanitizer: detected memory leaks Indirect leak of 359856 byte(s) in 459 object(s) allocated from: #0 0x7ffff7511df4 (/usr/lib64/clang/16/lib/linux/libclang_rt.asan-powerpc64le.so+0x191df4) (BuildId: 47e1dd371a2b8525b6cb737760a4dc535f30ea10) #1 0x7ffff6bb5fb0 in message_from_header /systemd-meson-build/../root/systemd/src/libsystemd/sd-bus/bus-message.c:372:13 #2 0x7ffff6bb5fb0 in bus_message_from_malloc /systemd-meson-build/../root/systemd/src/libsystemd/sd-bus/bus-message.c:421:13 #3 0x7ffff6c23f54 in bus_socket_make_message /systemd-meson-build/../root/systemd/src/libsystemd/sd-bus/bus-socket.c:1222:13 #4 0x7ffff6c22d10 in bus_socket_read_message /systemd-meson-build/../root/systemd/src/libsystemd/sd-bus/bus-socket.c #5 0x7ffff6c4d414 in bus_read_message /systemd-meson-build/../root/systemd/src/libsystemd/sd-bus/sd-bus.c:2082:16 #6 0x7ffff6c4d414 in sd_bus_call /systemd-meson-build/../root/systemd/src/libsystemd/sd-bus/sd-bus.c:2480:21 #7 0x7ffff6682904 in bus_service_manager_reload /systemd-meson-build/../root/systemd/src/shared/bus-unit-util.c:2823:13 #8 0x1000d570 in daemon_reload /systemd-meson-build/../root/systemd/src/sysext/sysext.c:233:16 #9 0x100090f8 in merge /systemd-meson-build/../root/systemd/src/sysext/sysext.c:895:21 #10 0x10006ff4 in verb_merge /systemd-meson-build/../root/systemd/src/sysext/sysext.c:964:16 #11 0x7ffff69ae894 in dispatch_verb /systemd-meson-build/../root/systemd/src/shared/verbs.c:103:24 #12 0x10004570 in sysext_main /systemd-meson-build/../root/systemd/src/sysext/sysext.c:1194:16 #13 0x10004570 in run /systemd-meson-build/../root/systemd/src/sysext/sysext.c:1214:16 #14 0x10004570 in main /systemd-meson-build/../root/systemd/src/sysext/sysext.c:1217:1 #15 0x7ffff5f5a968 in generic_start_main.isra.0 (/lib64/libc.so.6+0x2a968) (BuildId: c218e04818632a05c23f6fdcca16f93e95ea7de2) #16 0x7ffff5f5ab00 in __libc_start_main (/lib64/libc.so.6+0x2ab00) (BuildId: c218e04818632a05c23f6fdcca16f93e95ea7de2) Indirect leak of 124984 byte(s) in 459 object(s) allocated from: ... #11 0x7ffff5f5a968 in generic_start_main.isra.0 (/lib64/libc.so.6+0x2a968) (BuildId: c218e04818632a05c23f6fdcca16f93e95ea7de2) #12 0x7ffff5f5ab00 in __libc_start_main (/lib64/libc.so.6+0x2ab00) (BuildId: c218e04818632a05c23f6fdcca16f93e95ea7de2) SUMMARY: AddressSanitizer: 493766 byte(s) leaked in 1383 allocation(s).
ssahani
pushed a commit
that referenced
this pull request
Sep 22, 2023
When exiting PID 1 we most likely don't have stdio/stdout open, so the final LSan check would not print any actionable information and would just crash PID 1 leading up to a kernel panic, which is a bit annoying. Let's instead attempt to open /dev/console, and if we succeed redirect LSan's report there. The result is a bit messy, as it's slightly interleaved with the kernel panic, but it's definitely better than not having the stack trace at all: [ OK ] Reached target final.target. [ OK ] Finished systemd-poweroff.service. [ OK ] Reached target poweroff.target. ================================================================= 3 1m 43.251782] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 43.252838] CPU: 2 PID: 1 Comm: systemd Not tainted 6.4.12-200.fc38.x86_64 #1 ==[1==ERR O R :4 3Le.a2k53562] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014 [ 43.254683] Call Trace: [ 43.254911] <TASK> [ 43.255107] dump_stack_lvl+0x47/0x60 S[ a 43.n2555i05] panic+t0x192/0x350 izer[ :43.255966 ] do_exit+0x990/0xdb10 etec[ 43.256504] do_group_exit+0x31/0x80 [ 43.256889] __x64_sys_exit_group+0x18/0x20 [ 43.257288] do_syscall_64+0x60/0x90 o_user_mod leaks[ 43.257618] ? syscall_exit_t +0x2b/0x40 [ 43.258411] ? do_syscall_64+0x6c/0x90 1mDirect le[ 43.258755] ak of 21 byte(s)? exc_page_fault+0x7f/0x180 [ 43.259446] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 43.259901] RiIP: 0033:0x7f357nb8f3ad4 1 objec[ 43.260354] Ctode: 48 89 (f7 0f 05 c3 sf3 0f 1e fa b8 3b 00 00 00) 0f 05 c3 0f 1f 4 0 00 f3 0f 1e fa 50 58 b8 e7 00 00 00 48 83 ec 08 48 63 ff 0f 051 [ 43.262581] RSP: 002b:00007ffc25872440 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7 a RBX: 00007f357be9b218 RCX: 00007f357b8f3ad4m:ffd [ 43.264512] RDX: 0000000000000001 RSI: 00007f357b933b63 RDI: 0000000000000001 [ 43.265355] RBP: 00007f357be9b218 R08: efffffffffffffff R09: 00007ffc258721ef [ 43.266191] R10: 000000000000003f R11: 0000000000000202 R12: 00000fe6ae9e0000 [ 43.266891] R13: 00007f3574f00000 R14: 0000000000000000 R15: 0000000000000007 [ 43.267517] </TASK> #0 0x7f357b8814a8 in strdup (/lib64/libasan.so.8+0x814a8) (BuildId: e5f0a0d511a659fbc47bf41072869139cb2db47f) #1 0x7f3578d43317 in cg_path_decode_unit ../src/basic/cgroup-util.c:1132 #2 0x7f3578d43936 in cg_path_get_unit ../src/basic/cgroup-util.c:1190 #3 0x7f3578d440f6 in cg_pid_get_unit ../src/basic/cgroup-util.c:1234 #4 0x7f35789263d7 in bus_log_caller ../src/shared/bus-util.c:734 #5 0x7f357a9cf10a in method_reload ../src/core/dbus-manager.c:1621 #6 0x7f3578f77497 in method_callbacks_run ../src/libsystemd/sd-bus/bus-objects.c:406 #7 0x7f3578f80dd8 in object_find_and_run ../src/libsystemd/sd-bus/bus-objects.c:1319 #8 0x7f3578f82487 in bus_process_object ../src/libsystemd/sd-bus/bus-objects.c:1439 #9 0x7f3578fe41f1 in process_message ../src/libsystemd/sd-bus/sd-bus.c:3007 #10 0x7f3578fe477b in process_running ../src/libsystemd/sd-bus/sd-bus.c:3049 #11 0x7f3578fe75d1 in bus_process_internal ../src/libsystemd/sd-bus/sd-bus.c:3269 #12 0x7f3578fe776e in sd_bus_process ../src/libsystemd/sd-bus/sd-bus.c:3296 #13 0x7f3578feaedc in io_callback ../src/libsystemd/sd-bus/sd-bus.c:3638 #14 0x7f35791c2f68 in source_dispatch ../src/libsystemd/sd-event/sd-event.c:4187 #15 0x7f35791cc6f9 in sd_event_dispatch ../src/libsystemd/sd-event/sd-event.c:4808 #16 0x7f35791cd830 in sd_event_run ../src/libsystemd/sd-event/sd-event.c:4869 #17 0x7f357abcd572 in manager_loop ../src/core/manager.c:3244 #18 0x41db21 in invoke_main_loop ../src/core/main.c:1960 #19 0x426615 in main ../src/core/main.c:3125 #20 0x7f3577c49b49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) #21 0x7f3577c49c0a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9) #22 0x408494 in _start (/usr/lib/systemd/systemd+0x408494) (BuildId: fe61e1b0f00b6a36aa34e707a98c15c52f6b960a) SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s). [ 43.295912] Kernel Offset: 0x7000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 43.297036] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 ]--- Originally noticed in systemd#28579.
ssahani
pushed a commit
that referenced
this pull request
Dec 13, 2023
fuzzers randomly fail with the following:
```
==172==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f41169cb39b in update_argv /work/build/../../src/systemd/src/basic/argv-util.c:96:13
#1 0x7f41169cb39b in rename_process /work/build/../../src/systemd/src/basic/argv-util.c:210:16
#2 0x7f4116b6824e in safe_fork_full /work/build/../../src/systemd/src/basic/process-util.c:1516:21
#3 0x7f4116bffa36 in safe_fork /work/build/../../src/systemd/src/basic/process-util.h:191:16
#4 0x7f4116bffa36 in parse_timestamp /work/build/../../src/systemd/src/basic/time-util.c:1047:13
#5 0x4a61e6 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-time-util.c:16:16
#6 0x4c4a13 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#7 0x4c41fa in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
#8 0x4c58c9 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
#9 0x4c6595 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
#10 0x4b58ff in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
#11 0x4def52 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#12 0x7f4115ea3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: e678fe54a5d2c2092f8e47eb0b33105e380f7340)
#13 0x41f5ad in _start (build-out/fuzz-time-util+0x41f5ad)
DEDUP_TOKEN: update_argv--rename_process--safe_fork_full
Uninitialized value was created by an allocation of 'fv' in the stack frame of function 'have_effective_cap'
#0 0x7f41169d3540 in have_effective_cap /work/build/../../src/systemd/src/basic/capability-util.c:21
```
ssahani
pushed a commit
that referenced
this pull request
Dec 13, 2023
By making assert_return() critical, we observe the following:
---
Program received signal SIGABRT, Aborted.
0x00007f01320b0884 in __pthread_kill_implementation () from /lib64/libc.so.6
(gdb) bt
#0 0x00007f01320b0884 in __pthread_kill_implementation ()
from /lib64/libc.so.6
#1 0x00007f013205fafe in raise () from /lib64/libc.so.6
#2 0x00007f013204887f in abort () from /lib64/libc.so.6
#3 0x00007f01338d02d6 in log_assert_failed (
text=0x7f01340009e0 "e->state != SD_EVENT_FINISHED",
file=0x7f0133fff403 "src/libsystemd/sd-event/sd-event.c", line=1399,
func=0x7f01340045a0 <__func__.148> "sd_event_add_time")
at ../src/basic/log.c:948
#4 0x00007f01338d0457 in log_assert_failed_return (
text=0x7f01340009e0 "e->state != SD_EVENT_FINISHED",
file=0x7f0133fff403 "src/libsystemd/sd-event/sd-event.c", line=1399,
func=0x7f01340045a0 <__func__.148> "sd_event_add_time")
at ../src/basic/log.c:967
#5 0x00007f0133c7ed83 in sd_event_add_time (e=0x617000022280,
ret=0x610000007e98, clock=7, usec=24054941030, accuracy=0,
callback=0x4625b4 <on_announcement_timeout>, userdata=0x610000007e40)
at ../src/libsystemd/sd-event/sd-event.c:1399
#6 0x00007f0133c7f725 in sd_event_add_time_relative (e=0x617000022280,
ret=0x610000007e98, clock=7, usec=1000000, accuracy=0,
callback=0x4625b4 <on_announcement_timeout>, userdata=0x610000007e40)
at ../src/libsystemd/sd-event/sd-event.c:1462
#7 0x0000000000464cac in dns_scope_announce (scope=0x610000007e40, goodbye=true) at ../src/resolve/resolved-dns-scope.c:1530
#8 0x0000000000504d08 in link_free (l=0x612000023d40) at ../src/resolve/resolved-link.c:83
#9 0x000000000052dbbd in manager_free (m=0x619000000a80) at ../src/resolve/resolved-manager.c:697
#10 0x0000000000562328 in manager_freep (p=0x7f012f800040) at ../src/resolve/resolved-manager.h:198
#11 0x000000000056315a in run (argc=1, argv=0x7fff22b06468) at ../src/resolve/resolved.c:25
#12 0x0000000000563284 in main (argc=1, argv=0x7fff22b06468) at ../src/resolve/resolved.c:99
---
Prompted by systemd#30049 (comment).
ssahani
pushed a commit
that referenced
this pull request
Dec 13, 2023
When assert_return() is critical, the following assertion is triggered on exit: --- #0 0x00007f8b1f6b0884 in __pthread_kill_implementation () from target:/lib64/libc.so.6 #1 0x00007f8b1f65fafe in raise () from target:/lib64/libc.so.6 #2 0x00007f8b1f64887f in abort () from target:/lib64/libc.so.6 #3 0x00007f8b208d02d6 in log_assert_failed (text=0x7f8b210009e0 "e->state != SD_EVENT_FINISHED", file=0x7f8b20fff403 "src/libsystemd/sd-event/sd-event.c", line=1252, func=0x7f8b21004400 <__func__.154> "sd_event_add_io") at ../src/basic/log.c:948 #4 0x00007f8b208d0457 in log_assert_failed_return (text=0x7f8b210009e0 "e->state != SD_EVENT_FINISHED", file=0x7f8b20fff403 "src/libsystemd/sd-event/sd-event.c", line=1252, func=0x7f8b21004400 <__func__.154> "sd_event_add_io") at ../src/basic/log.c:967 #5 0x00007f8b20c7d102 in sd_event_add_io (e=0x617000000080, ret=0x60c000000a20, fd=11, events=1, callback=0x7dfd85 <ipv4acd_on_packet>, userdata=0x60c000000a00) at ../src/libsystemd/sd-event/sd-event.c:1252 #6 0x00000000007e3934 in sd_ipv4acd_start (acd=0x60c000000a00, reset_conflicts=true) at ../src/libsystemd-network/sd-ipv4acd.c:597 #7 0x00000000007e72b9 in ipv4ll_start_internal (ll=0x6080000006a0, reset_generation=true) at ../src/libsystemd-network/sd-ipv4ll.c:278 #8 0x00000000007e7462 in sd_ipv4ll_start (ll=0x6080000006a0) at ../src/libsystemd-network/sd-ipv4ll.c:298 #9 0x00000000006047a1 in dhcp4_handler (client=0x617000000400, event=0, userdata=0x61a000000680) at ../src/network/networkd-dhcp4.c:1183 #10 0x000000000075b1ed in client_notify (client=0x617000000400, event=0) at ../src/libsystemd-network/sd-dhcp-client.c:783 #11 0x000000000075bf8d in client_stop (client=0x617000000400, error=0) at ../src/libsystemd-network/sd-dhcp-client.c:821 #12 0x000000000077710f in sd_dhcp_client_stop (client=0x617000000400) at ../src/libsystemd-network/sd-dhcp-client.c:2388 #13 0x000000000065cdd1 in link_stop_engines (link=0x61a000000680, may_keep_dhcp=true) at ../src/network/networkd-link.c:336 #14 0x000000000041f214 in manager_free (m=0x618000000080) at ../src/network/networkd-manager.c:613 #15 0x00000000004124e3 in manager_freep (p=0x7f8b1c800040) at ../src/network/networkd-manager.h:128 #16 0x00000000004139f6 in run (argc=1, argv=0x7ffffe4522e8) at ../src/network/networkd.c:24 #17 0x0000000000413b20 in main (argc=1, argv=0x7ffffe4522e8) at ../src/network/networkd.c:119 --- Prompted by systemd#30049 (comment).
ssahani
pushed a commit
that referenced
this pull request
Jan 4, 2024
Avoid passing a NULL message to sd_bus_message_is_signal(), to not trip over an assertion: [ 132.869436] H testsuite-82.sh[614]: + systemctl --no-block --check-inhibitors=yes soft-reboot [ 132.967386] H systemd[1]: Created slice system-systemd\x2dcoredump.slice. [ 133.018292] H systemd[1]: Starting inhibit.service... [ 133.122610] H systemd[1]: Started [email protected]. [ 133.163643] H systemd[1]: Started inhibit.service. [ 133.206836] H testsuite-82.sh[614]: + exec sleep infinity [ 133.236762] H systemd-logind[611]: The system will reboot now! [ 135.891607] H systemd-coredump[667]: [🡕] Process 663 (busctl) of user 0 dumped core. Stack trace of thread 663: #0 0x00007f2ec45e6acf raise (libc.so.6 + 0x4eacf) #1 0x00007f2ec45b9ea5 abort (libc.so.6 + 0x21ea5) #2 0x00007f2ec4b5c9a6 log_assert_failed (libsystemd-shared-255.so + 0x1ff9a6) #3 0x00007f2ec4b5dca5 log_assert_failed_return (libsystemd-shared-255.so + 0x200ca5) #4 0x00007f2ec4bb3df6 sd_bus_message_is_signal (libsystemd-shared-255.so + 0x256df6) #5 0x000000000040e478 monitor (busctl + 0xe478) #6 0x000000000040e82f verb_monitor (busctl + 0xe82f) #7 0x00007f2ec4b202cb dispatch_verb (libsystemd-shared-255.so + 0x1c32cb) #8 0x00000000004074fa busctl_main (busctl + 0x74fa) #9 0x0000000000407525 run (busctl + 0x7525) #10 0x000000000040ff67 main (busctl + 0xff67) #11 0x00007f2ec45d2d85 __libc_start_main (libc.so.6 + 0x3ad85) #12 0x00000000004044be _start (busctl + 0x44be) ELF object binary architecture: AMD x86-64 [ 136.141152] H dbus-daemon[634]: [system] Monitoring connection :1.2 closed. [ 136.152233] H systemd[1]: busctl.service: Main process exited, code=dumped, status=6/ABRT [ 136.153996] H systemd[1]: busctl.service: Failed with result 'core-dump'. The asertion in question: Assertion 'm' failed at src/libsystemd/sd-bus/bus-message.c:1015, function sd_bus_message_is_signal(). Aborting. We can get a NULL message here through sd_bus_process() -> bus_process_internal() -> process_running(), so let's handle this case appropriately.
ssahani
pushed a commit
that referenced
this pull request
Jan 4, 2024
Since in that case the event loop is already finished and we'd hit an assertion: [ 1295.993300] testsuite-75.sh[50]: + systemctl stop systemd-resolved.service [ 1296.005152] systemd-resolved[298]: Assertion 'e->state != SD_EVENT_FINISHED' failed at src/libsystemd/sd-event/sd-event.c:1252, function sd_event_add_io(). Aborting. Thread 1 (Thread 0x7f17d25e2940 (LWP 298)): #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007f17d16ac8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007f17d165c668 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007f17d16444b8 in __GI_abort () at abort.c:79 #4 0x00007f17d2402d2d in log_assert_failed (text=<optimized out>, file=<optimized out>, line=<optimized out>, func=<optimized out>) at ../build/src/basic/log.c:968 #5 0x00007f17d240401c in log_assert_failed_return (text=text@entry=0x7f17d2533f13 "e->state != SD_EVENT_FINISHED", file=file@entry=0x7f17d25195d9 "src/libsystemd/sd-event/sd-event.c", line=line@entry=1252, func=func@entry=0x7f17d2567260 <__func__.140> "sd_event_add_io") at ../build/src/basic/log.c:987 #6 0x00007f17d24d011a in sd_event_add_io (e=0x55e5cb497270, ret=0x55e5cb4a5120, fd=fd@entry=26, events=events@entry=1, callback=callback@entry=0x55e5caff5466 <on_io_event>, userdata=0x55e5cb4a5110) at ../build/src/libsystemd/sd-event/sd-event.c:1252 #7 0x000055e5caff571c in manager_add_socket_to_graveyard (m=0x55e5cb43cf00, fd=26) at ../build/src/resolve/resolved-socket-graveyard.c:117 #8 0x000055e5cafd4253 in dns_transaction_close_connection (t=t@entry=0x55e5cb57c7d0, use_graveyard=use_graveyard@entry=true) at ../build/src/resolve/resolved-dns-transaction.c:78 #9 0x000055e5cafd8444 in dns_transaction_complete (t=t@entry=0x55e5cb57c7d0, state=state@entry=DNS_TRANSACTION_ABORTED) at ../build/src/resolve/resolved-dns-transaction.c:427 #10 0x000055e5cafc4969 in dns_scope_abort_transactions (s=s@entry=0x55e5cb4b1a70) at ../build/src/resolve/resolved-dns-scope.c:91 #11 0x000055e5cafc6aee in dns_scope_free (s=0x55e5cb4b1a70) at ../build/src/resolve/resolved-dns-scope.c:106 #12 0x000055e5cafe72d1 in link_free (l=0x55e5cb4a5160) at ../build/src/resolve/resolved-link.c:94 #13 0x000055e5cafedefc in manager_free (m=0x55e5cb43cf00) at ../build/src/resolve/resolved-manager.c:697 #14 0x000055e5caff99b6 in manager_freep (p=p@entry=0x7ffd71fab8f8) at ../build/src/resolve/resolved-manager.h:198 #15 0x000055e5caff9d66 in run (argc=argc@entry=1, argv=argv@entry=0x7ffd71faba78) at ../build/src/resolve/resolved.c:25 #16 0x000055e5caff9fe3 in main (argc=1, argv=0x7ffd71faba78) at ../build/src/resolve/resolved.c:99 Resolves: systemd#30618
ssahani
pushed a commit
that referenced
this pull request
Jan 31, 2024
Since libfuzzer feeds a single fuzzing process with multiple inputs, we
might carry over arg_transport from a previous invocation, tripping over
the assert in acquire_bus():
+----------------------------------------Release Build Stacktrace----------------------------------------+
Assertion 'transport != BUS_TRANSPORT_REMOTE || runtime_scope == RUNTIME_SCOPE_SYSTEM' failed at src/shared/bus-util.c:284, function bus_connect_transport(). Aborting.
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2739==ERROR: AddressSanitizer: ABRT on unknown address 0x00000ab3 (pc 0xf7f52509 bp 0xffdf74cc sp 0xffdf74b0 T0)
SCARINESS: 10 (signal)
#0 0xf7f52509 in linux-gate.so.1
#1 0xf703b415 in raise
#2 0xf70233f6 in abort
#3 0xf772ac0a in log_assert_failed systemd/src/basic/log.c:968:9
#4 0xf77300d5 in log_assert_failed_return systemd/src/basic/log.c:987:17
#5 0xf7432bbf in bus_connect_transport systemd/src/shared/bus-util.c:284:9
#6 0x818cd17 in acquire_bus systemd/src/systemctl/systemctl-util.c:53:29
#7 0x815fd3c in help_boot_loader_entry systemd/src/systemctl/systemctl-logind.c:431:13
#8 0x819ca87 in systemctl_parse_argv systemd/src/systemctl/systemctl.c:863:37
#9 0x8197632 in systemctl_dispatch_parse_argv systemd/src/systemctl/systemctl.c:1137:16
#10 0x813328d in LLVMFuzzerTestOneInput systemd/src/systemctl/fuzz-systemctl-parse-argv.c:54:13
#11 0x81bbe7e in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned int) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#12 0x81bb5b8 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned int, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
#13 0x81bd42d in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:826:7
#14 0x81bd62e in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:857:3
#15 0x81ac84c in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned int)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
#16 0x81d65c7 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#17 0xf7024ed4 in __libc_start_main
#18 0x806bdb5 in _start
Resolves: systemd#30802
ssahani
pushed a commit
that referenced
this pull request
Sep 16, 2024
…ck policy So far you had to pick: 1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor blesses your setup via signature) or 2. Use a pcrlock policy (i.e. local system blesses your setup via dynamic local policy stored in NV index) It was not possible combine these two, because TPM2 access policies do not allow the combination of PolicyAuthorize (used to implement #1 above) and PolicyAuthorizeNV (used to implement #2) in a single policy, unless one is "further upstream" (and can simply remove the other from the policy freely). This is quite limiting of course, since we actually do want to enforce on each TPM object that both the OS vendor policy and the local policy must be fulfilled, without the chance for the vendor or the local system to disable the other. This patch addresses this: instead of trying to find a way to come up with some adventurous scheme to combine both policy into one TPM2 policy, we simply shard the symmetric LUKS decryption key: one half we protect via the signed PCR policy, and the other we protect via the pcrlock policy. Only if both halves can be acquired the disk can be decrypted. This means: 1. we simply double the unlock key in length in case both policies shall be used. 2. We store two resulting TPM policy hashes in the LUKS token JSON, one for each policy 3. We store two sealed TPM policy key blobs in the LUKS token JSON, for both halves of the LUKS unlock key. This patch keeps the "sharding" logic relatively generic (i.e. the low level logic is actually fine with more than 2 shards), because I figure sooner or later we might have to encode more shards, for example if we add further TPM2-based access policies, for example when combining FIDO2 with TPM2, or implementing TOTP for this.
ssahani
pushed a commit
that referenced
this pull request
Oct 16, 2024
…s with an explicit flag Let's mark functions that accept the 'more' flag explicitly for that, and validate for this explicitly. This is preparation for varlink/varlink.github.io#26, if we get that one day. Let's make sure that from day #1 we have this info available even if we don't generate this in the IDL for now. Also enables the two flags for all interfaces we export that use the logic.
ssahani
pushed a commit
that referenced
this pull request
Jan 6, 2025
All other usages of sd_varlink_call* do not free the json return parameter, and it is owned by the varlink object instead. Do the same here. TEST-54-CREDS.sh[1074]: ==1074==ERROR: AddressSanitizer: heap-use-after-free on address 0x50c00000095a at pc 0x55cf8cd18a0f bp 0x7ffd7b9d4f10 sp 0x7ffd7b9d4f08 TEST-54-CREDS.sh[1074]: READ of size 2 at 0x50c00000095a thread T0 ((sd-mkdcreds)) TEST-54-CREDS.sh[1074]: #0 0x55cf8cd18a0e in sd_json_variant_unref /usr/src/debug/systemd/src/libsystemd/sd-json/sd-json.c:887:16 TEST-54-CREDS.sh[1074]: #1 0x55cf8cd4cecb in varlink_clear_current /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:593:22 TEST-54-CREDS.sh[1074]: #2 0x55cf8cd4975e in varlink_clear /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:614:9 TEST-54-CREDS.sh[1074]: #3 0x55cf8cd3dc3c in varlink_destroy /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:651:9 TEST-54-CREDS.sh[1074]: #4 0x55cf8cd3dc3c in sd_varlink_unref /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:657:1 TEST-54-CREDS.sh[1074]: #5 0x55cf8cb47a82 in sd_varlink_unrefp /usr/src/debug/systemd/src/systemd/sd-varlink.h:279:1 TEST-54-CREDS.sh[1074]: #6 0x55cf8cb47a82 in ipc_decrypt_credential /usr/src/debug/systemd/src/shared/creds-util.c:1660:1 TEST-54-CREDS.sh[1074]: #7 0x55cf8caca99a in maybe_decrypt_and_write_credential /usr/src/debug/systemd/src/core/exec-credential.c:486:29 TEST-54-CREDS.sh[1074]: #8 0x55cf8cac790b in load_credential /usr/src/debug/systemd/src/core/exec-credential.c:713:16 TEST-54-CREDS.sh[1074]: #9 0x55cf8cac5403 in acquire_credentials /usr/src/debug/systemd/src/core/exec-credential.c:819:29 TEST-54-CREDS.sh[1074]: #10 0x55cf8cac5403 in setup_credentials_internal /usr/src/debug/systemd/src/core/exec-credential.c:1023:13 TEST-54-CREDS.sh[1074]: #11 0x55cf8cac42d4 in exec_setup_credentials /usr/src/debug/systemd/src/core/exec-credential.c:1168:21 TEST-54-CREDS.sh[1074]: #12 0x55cf8ca59569 in exec_invoke /usr/src/debug/systemd/src/core/exec-invoke.c:4866:13 TEST-54-CREDS.sh[1074]: #13 0x55cf8ca428d8 in run /usr/src/debug/systemd/src/core/executor.c:244:13 TEST-54-CREDS.sh[1074]: #14 0x55cf8ca428d8 in main /usr/src/debug/systemd/src/core/executor.c:275:13 TEST-54-CREDS.sh[1074]: #15 0x7f64b40110c7 in __libc_start_call_main (/lib64/libc.so.6+0x40c7) (BuildId: 159846287d47eef88f2a478f59803f6e8fc81d05) TEST-54-CREDS.sh[1074]: #16 0x7f64b401118a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x418a) (BuildId: 159846287d47eef88f2a478f59803f6e8fc81d05) TEST-54-CREDS.sh[1074]: #17 0x55cf8ca41cb4 (/usr/lib/systemd/systemd-executor+0x124cb4) (BuildId: 24f2b1608c3aaee3226cdd14fa2b6e6741156222) TEST-54-CREDS.sh[1074]: 0x50c00000095a is located 26 bytes inside of 120-byte region [0x50c000000940,0x50c0000009b8) TEST-54-CREDS.sh[1074]: freed by thread T0 ((sd-mkdcreds)) here: TEST-54-CREDS.sh[1074]: #0 0x7f64b48d57ea in free (/usr/lib/clang/19/lib/x86_64-redhat-linux-gnu/libclang_rt.asan.so+0xd57ea) (BuildId: c59bbd28ceb74038a60373d4a8cd4c258bcf0b4e) TEST-54-CREDS.sh[1074]: #1 0x55cf8cd188ab in sd_json_variant_unref /usr/src/debug/systemd/src/libsystemd/sd-json/sd-json.c:895:25 TEST-54-CREDS.sh[1074]: #2 0x55cf8cb47a4c in sd_json_variant_unrefp /usr/src/debug/systemd/src/systemd/sd-json.h:98:1 TEST-54-CREDS.sh[1074]: #3 0x55cf8cb47a4c in ipc_decrypt_credential /usr/src/debug/systemd/src/shared/creds-util.c:1660:1 TEST-54-CREDS.sh[1074]: #4 0x55cf8caca99a in maybe_decrypt_and_write_credential /usr/src/debug/systemd/src/core/exec-credential.c:486:29 TEST-54-CREDS.sh[1074]: #5 0x55cf8cac790b in load_credential /usr/src/debug/systemd/src/core/exec-credential.c:713:16 TEST-54-CREDS.sh[1074]: #6 0x55cf8cac5403 in acquire_credentials /usr/src/debug/systemd/src/core/exec-credential.c:819:29 TEST-54-CREDS.sh[1074]: #7 0x55cf8cac5403 in setup_credentials_internal /usr/src/debug/systemd/src/core/exec-credential.c:1023:13 TEST-54-CREDS.sh[1074]: #8 0x55cf8cac42d4 in exec_setup_credentials /usr/src/debug/systemd/src/core/exec-credential.c:1168:21 TEST-54-CREDS.sh[1074]: #9 0x55cf8ca59569 in exec_invoke /usr/src/debug/systemd/src/core/exec-invoke.c:4866:13 TEST-54-CREDS.sh[1074]: #10 0x55cf8ca428d8 in run /usr/src/debug/systemd/src/core/executor.c:244:13 TEST-54-CREDS.sh[1074]: #11 0x55cf8ca428d8 in main /usr/src/debug/systemd/src/core/executor.c:275:13 TEST-54-CREDS.sh[1074]: #12 0x7f64b40110c7 in __libc_start_call_main (/lib64/libc.so.6+0x40c7) (BuildId: 159846287d47eef88f2a478f59803f6e8fc81d05) TEST-54-CREDS.sh[1074]: #13 0x7f64b401118a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x418a) (BuildId: 159846287d47eef88f2a478f59803f6e8fc81d05) TEST-54-CREDS.sh[1074]: #14 0x55cf8ca41cb4 (/usr/lib/systemd/systemd-executor+0x124cb4) (BuildId: 24f2b1608c3aaee3226cdd14fa2b6e6741156222) TEST-54-CREDS.sh[1074]: previously allocated by thread T0 ((sd-mkdcreds)) here: TEST-54-CREDS.sh[1074]: #0 0x7f64b48d5a83 in malloc (/usr/lib/clang/19/lib/x86_64-redhat-linux-gnu/libclang_rt.asan.so+0xd5a83) (BuildId: c59bbd28ceb74038a60373d4a8cd4c258bcf0b4e) TEST-54-CREDS.sh[1074]: #1 0x55cf8cd16bb7 in malloc_multiply /usr/src/debug/systemd/src/basic/alloc-util.h:119:16 TEST-54-CREDS.sh[1074]: #2 0x55cf8cd16bb7 in sd_json_variant_new_object /usr/src/debug/systemd/src/libsystemd/sd-json/sd-json.c:737:13 TEST-54-CREDS.sh[1074]: #3 0x55cf8cd32e58 in json_parse_internal /usr/src/debug/systemd/src/libsystemd/sd-json/sd-json.c:3161:29 TEST-54-CREDS.sh[1074]: #4 0x55cf8cd37326 in sd_json_parse_with_source /usr/src/debug/systemd/src/libsystemd/sd-json/sd-json.c:3408:16 TEST-54-CREDS.sh[1074]: #5 0x55cf8cd37326 in sd_json_parse /usr/src/debug/systemd/src/libsystemd/sd-json/sd-json.c:3437:16 TEST-54-CREDS.sh[1074]: #6 0x55cf8cd3f753 in varlink_parse_message /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:962:13 TEST-54-CREDS.sh[1074]: #7 0x55cf8cd3f753 in sd_varlink_process /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:1466:13 TEST-54-CREDS.sh[1074]: #8 0x55cf8cd4c0a9 in sd_varlink_call_full /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:2160:21 TEST-54-CREDS.sh[1074]: #9 0x55cf8cd4d617 in sd_varlink_callb_ap /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:2237:16 TEST-54-CREDS.sh[1074]: #10 0x55cf8cd4da3c in sd_varlink_callb /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:2251:13 TEST-54-CREDS.sh[1074]: #11 0x55cf8cb47686 in ipc_decrypt_credential /usr/src/debug/systemd/src/shared/creds-util.c:1623:13 TEST-54-CREDS.sh[1074]: #12 0x55cf8caca99a in maybe_decrypt_and_write_credential /usr/src/debug/systemd/src/core/exec-credential.c:486:29 TEST-54-CREDS.sh[1074]: #13 0x55cf8cac790b in load_credential /usr/src/debug/systemd/src/core/exec-credential.c:713:16 TEST-54-CREDS.sh[1074]: #14 0x55cf8cac5403 in acquire_credentials /usr/src/debug/systemd/src/core/exec-credential.c:819:29 TEST-54-CREDS.sh[1074]: #15 0x55cf8cac5403 in setup_credentials_internal /usr/src/debug/systemd/src/core/exec-credential.c:1023:13 TEST-54-CREDS.sh[1074]: #16 0x55cf8cac42d4 in exec_setup_credentials /usr/src/debug/systemd/src/core/exec-credential.c:1168:21 TEST-54-CREDS.sh[1074]: #17 0x55cf8ca59569 in exec_invoke /usr/src/debug/systemd/src/core/exec-invoke.c:4866:13 TEST-54-CREDS.sh[1074]: #18 0x55cf8ca428d8 in run /usr/src/debug/systemd/src/core/executor.c:244:13 TEST-54-CREDS.sh[1074]: #19 0x55cf8ca428d8 in main /usr/src/debug/systemd/src/core/executor.c:275:13 TEST-54-CREDS.sh[1074]: #20 0x7f64b40110c7 in __libc_start_call_main (/lib64/libc.so.6+0x40c7) (BuildId: 159846287d47eef88f2a478f59803f6e8fc81d05) TEST-54-CREDS.sh[1074]: #21 0x7f64b401118a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x418a) (BuildId: 159846287d47eef88f2a478f59803f6e8fc81d05) TEST-54-CREDS.sh[1074]: #22 0x55cf8ca41cb4 (/usr/lib/systemd/systemd-executor+0x124cb4) (BuildId: 24f2b1608c3aaee3226cdd14fa2b6e6741156222) TEST-54-CREDS.sh[1074]: SUMMARY: AddressSanitizer: heap-use-after-free /usr/src/debug/systemd/src/libsystemd/sd-json/sd-json.c:887:16 in sd_json_variant_unref TEST-54-CREDS.sh[1074]: Shadow bytes around the buggy address: TEST-54-CREDS.sh[1074]: 0x50c000000680: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa TEST-54-CREDS.sh[1074]: 0x50c000000700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd TEST-54-CREDS.sh[1074]: 0x50c000000780: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 TEST-54-CREDS.sh[1074]: 0x50c000000800: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa TEST-54-CREDS.sh[1074]: 0x50c000000880: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa TEST-54-CREDS.sh[1074]: =>0x50c000000900: fa fa fa fa fa fa fa fa fd fd fd[fd]fd fd fd fd TEST-54-CREDS.sh[1074]: 0x50c000000980: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa TEST-54-CREDS.sh[1074]: 0x50c000000a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa TEST-54-CREDS.sh[1074]: 0x50c000000a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa TEST-54-CREDS.sh[1074]: 0x50c000000b00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa TEST-54-CREDS.sh[1074]: 0x50c000000b80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa TEST-54-CREDS.sh[1074]: Shadow byte legend (one shadow byte represents 8 application bytes): TEST-54-CREDS.sh[1074]: Addressable: 00 TEST-54-CREDS.sh[1074]: Partially addressable: 01 02 03 04 05 06 07 TEST-54-CREDS.sh[1074]: Heap left redzone: fa TEST-54-CREDS.sh[1074]: Freed heap region: fd TEST-54-CREDS.sh[1074]: Stack left redzone: f1 TEST-54-CREDS.sh[1074]: Stack mid redzone: f2 TEST-54-CREDS.sh[1074]: Stack right redzone: f3 TEST-54-CREDS.sh[1074]: Stack after return: f5 TEST-54-CREDS.sh[1074]: Stack use after scope: f8 TEST-54-CREDS.sh[1074]: Global redzone: f9 TEST-54-CREDS.sh[1074]: Global init order: f6 TEST-54-CREDS.sh[1074]: Poisoned by user: f7 TEST-54-CREDS.sh[1074]: Container overflow: fc TEST-54-CREDS.sh[1074]: Array cookie: ac TEST-54-CREDS.sh[1074]: Intra object redzone: bb TEST-54-CREDS.sh[1074]: ASan internal: fe TEST-54-CREDS.sh[1074]: Left alloca redzone: ca TEST-54-CREDS.sh[1074]: Right alloca redzone: cb Follow-up for 2c3cbc5
ssahani
pushed a commit
that referenced
this pull request
Mar 5, 2025
ssahani
pushed a commit
that referenced
this pull request
Mar 5, 2025
ssahani
pushed a commit
that referenced
this pull request
Mar 5, 2025
This one is between "efi" and "linux": we'll recognize such entries as linux, but we'll just invoke them as EFI binaries. This creates a high-level concept for invoking UKIs via indirection of a bls type #1 entry, for example to permit invocation from a non-standard path or for giving entries a different name. Companion BLS spec PR: uapi-group/specifications#135 (Let's rename LOADER_UNIFIED_LINUX to LOADER_TYPE2_UKI at the same time to reduce confusion what is what)
ssahani
pushed a commit
that referenced
this pull request
Mar 5, 2025
Companion BLS spec PR: uapi-group/specifications#135
ssahani
pushed a commit
that referenced
this pull request
Mar 5, 2025
With this we can now do: systemd-vmspawn -n -i foobar.raw -s io.systemd.boot.entries-extra:particleos-current.conf=$'title ParticleOS Current\nuki-url http://example.com/somedir/uki.efi' Assuming sd-boot is available inside the ESP of foobar.raw a new item will show up in the boot menu that allows booting directly into the specified UKI.
ssahani
pushed a commit
that referenced
this pull request
Jun 18, 2025
…r() and friends
The buffer will be used by a library outside of our code base,
and may not be initialized even on success. Let's initialize
them for safety.
Hopefully fixes the following fuzzer warning:
```
==2039==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f9ad8be3ae6 in _nss_files_getsgnam_r (/lib/x86_64-linux-gnu/libnss_files.so.2+0x8ae6) (BuildId: 013bf05b4846ebbdbebdb05585acc9726c2fabce)
#1 0x7f9ad93e5902 in getsgnam_r (/lib/x86_64-linux-gnu/libc.so.6+0x126902) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
#2 0x7f9ad9b98153 in nss_sgrp_for_group /work/build/../../src/systemd/src/shared/user-record-nss.c:357:21
#3 0x7f9ad9b98926 in nss_group_record_by_gid /work/build/../../src/systemd/src/shared/user-record-nss.c:431:21
#4 0x7f9ad9bcebd7 in groupdb_by_gid_fallbacks /work/build/../../src/systemd/src/shared/userdb.c:1372:29
Uninitialized value was created by a heap allocation
#0 0x556fd5294302 in malloc /src/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:1021:3
#1 0x7f9ad9b9811d in nss_sgrp_for_group /work/build/../../src/systemd/src/shared/user-record-nss.c:353:23
#2 0x7f9ad9b98926 in nss_group_record_by_gid /work/build/../../src/systemd/src/shared/user-record-nss.c:431:21
#3 0x7f9ad9bcebd7 in groupdb_by_gid_fallbacks /work/build/../../src/systemd/src/shared/userdb.c:1372:29
```
ssahani
pushed a commit
that referenced
this pull request
Jun 18, 2025
The following failure should be in libxkbcommon and/or sanitizer.
There is nothing we can do here. Let's skip it.
```
TEST-73-LOCALE.sh[3733]: + assert_rc 0 localectl set-keymap lv
TEST-73-LOCALE.sh[6699]: + set +ex
TEST-73-LOCALE.sh[6700]: Failed to set keymap: Remote peer disconnected
TEST-73-LOCALE.sh[6703]: FAIL: expected: '0' actual: '1'
TEST-73-LOCALE.sh[157]: + rm -f /etc/dbus-1/system.d/systemd-localed-read-only.conf
[FAILED] Failed to start TEST-73-LOCALE.service - TEST-73-LOCALE.
```
```
==3719==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fa51f161000 at pc 0x7fa521250be4 bp 0x7ffe49130a80 sp 0x7ffe49130240
READ of size 19126 at 0x7fa51f161000 thread T0
#0 0x7fa521250be3 in strndup (/usr/lib/clang/20/lib/x86_64-redhat-linux-gnu/libclang_rt.asan.so+0x50be3) (BuildId: aa6231e817f72469c44a6c6cee9f0694a87db7fb)
#1 0x7fa51f128325 (/lib64/libxkbcommon.so.0+0x1c325) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
#2 0x7fa51f121952 (/lib64/libxkbcommon.so.0+0x15952) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
#3 0x7fa51f123d3a (/lib64/libxkbcommon.so.0+0x17d3a) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
#4 0x7fa51f117c86 (/lib64/libxkbcommon.so.0+0xbc86) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
#5 0x7fa51f12548f (/lib64/libxkbcommon.so.0+0x1948f) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
#6 0x7fa51f125c9e (/lib64/libxkbcommon.so.0+0x19c9e) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
#7 0x7fa51f126a59 (/lib64/libxkbcommon.so.0+0x1aa59) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
#8 0x7fa51f12cec6 (/lib64/libxkbcommon.so.0+0x20ec6) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
#9 0x7fa51f12e3c2 (/lib64/libxkbcommon.so.0+0x223c2) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
#10 0x7fa51f12a4e5 in xkb_keymap_new_from_names (/lib64/libxkbcommon.so.0+0x1e4e5) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
#11 0x5574dd63f864 in verify_xkb_rmlvo /usr/src/debug/systemd/src/locale/xkbcommon-util.c:69:14
(snip)
```
ssahani
pushed a commit
that referenced
this pull request
Jun 18, 2025
ssahani
pushed a commit
that referenced
this pull request
Aug 19, 2025
When check_access() was added, the callback data parameter was changed from a pointer to a double pointer, resulting in a crash when it is accessed when logging an error: #0 __internal_syscall_cancel (a1=a1@entry=0, a2=a2@entry=0, a3=a3@entry=140726176497168, a4=a4@entry=4, a5=a5@entry=0, a6=a6@entry=0, nr=247) at ./nptl/cancellation.c:44 #1 0x00007f5d0ec996ad in __syscall_cancel (a1=a1@entry=0, a2=a2@entry=0, a3=a3@entry=140726176497168, a4=a4@entry=4, a5=a5@entry=0, a6=a6@entry=0, nr=247) at ./nptl/cancellation.c:75 #2 0x00007f5d0ed047ab in __waitid (idtype=idtype@entry=P_ALL, id=id@entry=0, infop=infop@entry=0x7ffd5dc2be10, options=options@entry=4) at ../sysdeps/unix/sysv/linux/waitid.c:29 #3 0x00007f5d0f044412 in freeze () at ../src/basic/process-util.c:2039 #4 0x00005568f181bc2a in freeze_or_exit_or_reboot () at ../src/core/crash-handler.c:55 #5 0x00005568f181be82 in crash (sig=<optimized out>, siginfo=<optimized out>, context=<optimized out>) at ../src/core/crash-handler.c:184 #6 <signal handler called> #7 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76 #8 0x00007f5d0ec6e300 in __printf_buffer (buf=buf@entry=0x7ffd5dc2ca90, format=0x7f5d0f196e60 "%s: Failed to acquire credentials: %m", ap=0x7ffd5dc2d3d0, mode_flags=2) at ./stdio-common/vfprintf-process-arg.c:435 #9 0x00007f5d0ec91daf in __vsnprintf_internal (string=string@entry=0x7ffd5dc2cb70 "", maxlen=maxlen@entry=2048, format=format@entry=0x7f5d0f196e60 "%s: Failed to acquire credentials: %m", args=args@entry=0x7ffd5dc2d3d0, mode_flags=mode_flags@entry=2) at ./libio/vsnprintf.c:96 #10 0x00007f5d0ed27044 in ___vsnprintf_chk (s=s@entry=0x7ffd5dc2cb70 "", maxlen=maxlen@entry=2048, flag=flag@entry=1, slen=slen@entry=2048, format=format@entry=0x7f5d0f196e60 "%s: Failed to acquire credentials: %m", ap=ap@entry=0x7ffd5dc2d3d0) at ./debug/vsnprintf_chk.c:34 #11 0x00007f5d0f02de59 in vsnprintf (__s=0x7ffd5dc2cb70 "", __n=2048, __fmt=0x7f5d0f196e60 "%s: Failed to acquire credentials: %m", __ap=0x7ffd5dc2d3d0) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:100 #12 log_internalv (level=7, error=-9, file=0x7f5d0f196643 "src/libsystemd/sd-varlink/sd-varlink.c", line=2853, func=0x7f5d0f1d5ca0 <__func__.62> "sd_varlink_get_peer_uid", format=0x7f5d0f196e60 "%s: Failed to acquire credentials: %m", ap=0x7ffd5dc2d3d0) at ../src/basic/log.c:865 #13 0x00007f5d0f02ded5 in log_internalv (level=<optimized out>, error=<optimized out>, file=<optimized out>, line=<optimized out>, func=<optimized out>, format=<optimized out>, ap=0x7ffd5dc2d3d0) at ../src/basic/log.c:868 #14 0x00007f5d0f02df67 in log_internal (level=<optimized out>, error=<optimized out>, file=<optimized out>, line=<optimized out>, func=<optimized out>, format=<optimized out>) at ../src/basic/log.c:882 #15 0x00007f5d0f10a135 in sd_varlink_get_peer_uid (v=0x7f5d0f5ab110 <__func__.44>, ret=ret@entry=0x7ffd5dc2d4f0) at ../src/libsystemd/sd-varlink/sd-varlink.c:2853 #16 0x00007f5d0f50c29e in audit_callback (auditdata=0x7ffd5dc2d698, cls=<optimized out>, msgbuf=0x55692366e77d "", msgbufsize=995) at ../src/core/selinux-access.c:65 #17 0x00007f5d0f716079 in avc_suppl_audit (ptr=0x7ffd5dc2d698, class=95, buf=<optimized out>, len=<optimized out>) at ./src/avc_internal.h:101 #18 avc_audit (ssid=0x5569237f2890, tsid=0x556922d7f4b0, tclass=<optimized out>, requested=<optimized out>, avd=<optimized out>, result=0, a=0x7ffd5dc2d698) at ./src/avc.c:721 #19 0x00007f5d0f716367 in avc_has_perm (ssid=0x5569237f2890, tsid=0x556922d7f4b0, tclass=tclass@entry=95, requested=4, aeref=aeref@entry=0x0, auditdata=auditdata@entry=0x7ffd5dc2d698) at ./src/avc.c:836 #20 0x00007f5d0f718b0a in selinux_check_access (scon=scon@entry=0x55692384cbc0 "system_u:system_r:policykit_t:s0", tcon=tcon@entry=0x556922c98a20 "system_u:object_r:systemd_networkd_unit_t:s0", class=class@entry=0x7f5d0f580b9e "service", perm=perm@entry=0x7f5d0f580cc0 "status", aux=aux@entry=0x7ffd5dc2d698) at ./src/checkAccess.c:64 #21 0x00007f5d0f50bf7e in check_access (scon=0x55692384cbc0 "system_u:system_r:policykit_t:s0", tcon=0x556922c98a20 "system_u:object_r:systemd_networkd_unit_t:s0", tclass=0x7f5d0f580b9e "service", permission=permission@entry=0x7f5d0f580cc0 "status", audit_info=<optimized out>, audit_info@entry=0x7ffd5dc2d720, error=error@entry=0x7ffd5dc2d880) at ../src/core/selinux-access.c:229 #22 0x00007f5d0f5100a1 in mac_selinux_access_check_bus_internal (message=<optimized out>, unit=<optimized out>, permission=0x7f5d0f580cc0 "status", function=0x7f5d0f5ab110 <__func__.44> "method_get_unit_by_pidfd", error=0x7ffd5dc2d880) at ../src/core/selinux-access.c:329 #23 0x00007f5d0f4a024b in method_get_unit_by_pidfd (message=0x5569236d9010, userdata=<optimized out>, error=0x7ffd5dc2d880) at ../src/core/dbus-manager.c:657 #24 0x00007f5d0f0c9bd0 in method_callbacks_run (bus=0x5569238684e0, m=0x5569236d9010, c=<optimized out>, require_fallback=false, found_object=0x7ffd5dc2d947) at ../src/libsystemd/sd-bus/bus-objects.c:413 #25 object_find_and_run (bus=bus@entry=0x5569238684e0, m=m@entry=0x5569236d9010, p=<optimized out>, require_fallback=require_fallback@entry=false, found_object=found_object@entry=0x7ffd5dc2d947) at ../src/libsystemd/sd-bus/bus-objects.c:1323 #26 0x00007f5d0f0cafa2 in bus_process_object (bus=0x5569238684e0, m=0x5569236d9010) at ../src/libsystemd/sd-bus/bus-objects.c:1443 #27 0x00007f5d0f0d8c3e in process_message (bus=0x5569238684e0, m=0x5569236d9010) at ../src/libsystemd/sd-bus/sd-bus.c:3006 #28 process_running (bus=0x5569238684e0, ret=0x0) at ../src/libsystemd/sd-bus/sd-bus.c:3048 #29 bus_process_internal (bus=bus@entry=0x5569238684e0, ret=ret@entry=0x0) at ../src/libsystemd/sd-bus/sd-bus.c:3275 #30 0x00007f5d0f0d9099 in sd_bus_process (bus=bus@entry=0x5569238684e0, ret=ret@entry=0x0) at ../src/libsystemd/sd-bus/sd-bus.c:3302 #31 0x00007f5d0f0db3ec in io_callback (s=<optimized out>, fd=<optimized out>, revents=<optimized out>, userdata=0x5569238684e0) at ../src/libsystemd/sd-bus/sd-bus.c:3643 #32 0x00007f5d0f0a53d9 in source_dispatch (s=s@entry=0x5569236dea60) at ../src/libsystemd/sd-event/sd-event.c:4163 #33 0x00007f5d0f0a563d in sd_event_dispatch (e=<optimized out>, e@entry=0x5569232f6c00) at ../src/libsystemd/sd-event/sd-event.c:4782 #34 0x00007f5d0f0a6d38 in sd_event_run (e=<optimized out>, timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:4843 #35 0x00007f5d0f4f7871 in manager_loop (m=m@entry=0x5569232f8250) at ../src/core/manager.c:3310 #36 0x00005568f181517d in invoke_main_loop (m=0x5569232f8250, saved_rlimit_nofile=0x7ffd5dc2dcb0, saved_rlimit_memlock=0x7ffd5dc2dca0, ret_retval=<synthetic pointer>, ret_fds=0x7ffd5dc2dc78, ret_switch_root_dir=<synthetic pointer>, ret_switch_root_init=<synthetic pointer>, ret_error_message=0x7ffd5dc2dc90) at ../src/core/main.c:2140 #37 main (argc=<optimized out>, argv=0x7ffd5dc2dfe8) at ../src/core/main.c:3351 Follow-up for fe3f2ac
ssahani
pushed a commit
that referenced
this pull request
Nov 7, 2025
This test occasionally fails due to a race where systemd processes kernel's SIGKILL before the OOM notification, so the test service dies with Result=signal instead of the expected Result=oom-kill: [ 51.008765] TEST-55-OOMD.sh[906]: + systemd-run --wait --unit oom-kill -p OOMPolicy=kill -p Delegate=yes -p DelegateSubgroup=init.scope /tmp/script.sh [ 51.048747] TEST-55-OOMD.sh[907]: Running as unit: oom-kill.service; invocation ID: 456645347d554ea2878463404b181bd8 [ 51.066296] sysrq: Manual OOM execution [ 51.066596] kworker/1:0 invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL), order=-1, oom_score_adj=0 [ 51.066915] CPU: 1 UID: 0 PID: 27 Comm: kworker/1:0 Not tainted 6.17.1-arch1-1 #1 PREEMPT(full) d2b229857b2eb4001337041f41d3c4f131433540 [ 51.066919] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.17.0-2-2 04/01/2014 [ 51.066921] Workqueue: events moom_callback [ 51.066928] Call Trace: [ 51.066931] <TASK> [ 51.066936] dump_stack_lvl+0x5d/0x80 [ 51.066942] dump_header+0x43/0x1aa <...snip...> [ 51.087814] 47583 pages reserved [ 51.087969] 0 pages cma reserved [ 51.088208] 0 pages hwpoisoned [ 51.088519] Out of memory: Killed process 908 (sleep) total-vm:3264kB, anon-rss:256kB, file-rss:1916kB, shmem-rss:0kB, UID:0 pgtables:44kB oom_score_adj:1000 [ 51.090263] TEST-55-OOMD.sh[907]: Finished with result: signal [ 51.094416] TEST-55-OOMD.sh[907]: Main processes terminated with: code=killed, status=9/KILL [ 51.094898] TEST-55-OOMD.sh[907]: Service runtime: 58ms [ 51.095436] TEST-55-OOMD.sh[907]: CPU time consumed: 22ms [ 51.095854] TEST-55-OOMD.sh[907]: Memory peak: 1.6M (swap: 0B) [ 51.096722] TEST-55-OOMD.sh[912]: ++ systemctl show oom-kill -P Result [ 51.106549] TEST-55-OOMD.sh[879]: + assert_eq signal oom-kill [ 51.107394] TEST-55-OOMD.sh[913]: + set +ex [ 51.108256] TEST-55-OOMD.sh[913]: FAIL: expected: 'oom-kill' actual: 'signal' [FAILED] Failed to start TEST-55-OOMD.service. To mitigate this, let's spawn a child process and move it to the subcgroup to get killed instead of the main process, so systemd has more time to react to the OOM notification and terminate the service with the expected oom-kill result.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
dependencies
Pull requests that update a dependency file
github_actions
Pull requests that update Github_actions code
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bumps systemd/mkosi from 10 to 12.
Changelog
Sourced from systemd/mkosi's changelog.
... (truncated)
Commits
bf884c3Bump version numbers for v1243505eaNEWS: add entries for v125c77e78gentoo: unmerge baselayout early on.044d517Merge pull request #860 from bluca/lintian8e33f65resources: add +x to bash scripts909c7e1mkosi: fix typos found by Lintianf7d518eNEWS: c11 is actually released now, fix the NEWS entry post-tag6575c82Bump version numbers for v11bb3d7bbman: rebuild the man pageb8ca4dbtools/do-a-release: rebuild the man page in a separate commitDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)