nspawn: wait for network namespace creation before interface setup (#… #2

ghost · 2018-04-21T13:09:41Z

…8633)

Otherwise, network interfaces can be "moved" into the container's
namespace while it's still the same as the host namespace, in which case
e.g. host0 for a veth ends up on the host side instead of inside the
container.

Regression introduced in 0441378.

Fixes #8599.

(cherry picked from commit 7511655)

…8633) Otherwise, network interfaces can be "moved" into the container's namespace while it's still the same as the host namespace, in which case e.g. host0 for a veth ends up on the host side instead of inside the container. Regression introduced in 0441378. Fixes #8599. (cherry picked from commit 7511655)

`fuzz-journal-remote` seems to be failing under `msan` as soon as it starts: $ sudo infra/helper.py run_fuzzer systemd fuzz-journal-remote Running: docker run --rm -i --privileged -e FUZZING_ENGINE=libfuzzer -v /home/vagrant/oss-fuzz/build/out/systemd:/out -t gcr.io/oss-fuzz-base/base-runner run_fuzzer fuzz-journal-remote Using seed corpus: fuzz-journal-remote_seed_corpus.zip /out/fuzz-journal-remote -rss_limit_mb=2048 -timeout=25 /tmp/fuzz-journal-remote_corpus -max_len=65536 < /dev/null INFO: Seed: 3380449479 INFO: Loaded 2 modules (36336 inline 8-bit counters): 36139 [0x7ff36ea31d39, 0x7ff36ea3aa64), 197 [0x9998c8, 0x99998d), INFO: Loaded 2 PC tables (36336 PCs): 36139 [0x7ff36ea3aa68,0x7ff36eac7d18), 197 [0x999990,0x99a5e0), INFO: 2 files found in /tmp/fuzz-journal-remote_corpus INFO: seed corpus: files: 2 min: 4657b max: 7790b total: 12447b rss: 97Mb Uninitialized bytes in __interceptor_pwrite64 at offset 24 inside [0x7fffdd4d7230, 240) ==15==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7ff36e685e8a in journal_file_init_header /work/build/../../src/systemd/src/journal/journal-file.c:436:13 #1 0x7ff36e683a9d in journal_file_open /work/build/../../src/systemd/src/journal/journal-file.c:3333:21 #2 0x7ff36e68b8f6 in journal_file_open_reliably /work/build/../../src/systemd/src/journal/journal-file.c:3520:13 #3 0x4a3f35 in open_output /work/build/../../src/systemd/src/journal-remote/journal-remote.c:70:13 #4 0x4a34d0 in journal_remote_get_writer /work/build/../../src/systemd/src/journal-remote/journal-remote.c:136:21 #5 0x4a550f in get_source_for_fd /work/build/../../src/systemd/src/journal-remote/journal-remote.c:183:13 #6 0x4a46bd in journal_remote_add_source /work/build/../../src/systemd/src/journal-remote/journal-remote.c:235:13 #7 0x4a271c in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journal-remote.c:36:9 #8 0x4f27cc in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:524:13 #9 0x4efa0b in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:448:3 #10 0x4f8e96 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:732:7 #11 0x4f9f73 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:752:3 #12 0x4bf329 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:756:6 #13 0x4ac391 in main /src/libfuzzer/FuzzerMain.cpp:20:10 #14 0x7ff36d14982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #15 0x41f9d8 in _start (/out/fuzz-journal-remote+0x41f9d8) Uninitialized value was stored to memory at #0 0x7ff36e61cd41 in sd_id128_randomize /work/build/../../src/systemd/src/libsystemd/sd-id128/sd-id128.c:288:16 #1 0x7ff36e685cec in journal_file_init_header /work/build/../../src/systemd/src/journal/journal-file.c:426:13 #2 0x7ff36e683a9d in journal_file_open /work/build/../../src/systemd/src/journal/journal-file.c:3333:21 #3 0x7ff36e68b8f6 in journal_file_open_reliably /work/build/../../src/systemd/src/journal/journal-file.c:3520:13 #4 0x4a3f35 in open_output /work/build/../../src/systemd/src/journal-remote/journal-remote.c:70:13 #5 0x4a34d0 in journal_remote_get_writer /work/build/../../src/systemd/src/journal-remote/journal-remote.c:136:21 #6 0x4a550f in get_source_for_fd /work/build/../../src/systemd/src/journal-remote/journal-remote.c:183:13 #7 0x4a46bd in journal_remote_add_source /work/build/../../src/systemd/src/journal-remote/journal-remote.c:235:13 #8 0x4a271c in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journal-remote.c:36:9 #9 0x4f27cc in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:524:13 #10 0x4efa0b in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:448:3 #11 0x4f8e96 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:732:7 #12 0x4f9f73 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:752:3 #13 0x4bf329 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:756:6 #14 0x4ac391 in main /src/libfuzzer/FuzzerMain.cpp:20:10 #15 0x7ff36d14982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) Uninitialized value was created by an allocation of 't' in the stack frame of function 'sd_id128_randomize' #0 0x7ff36e61cb00 in sd_id128_randomize /work/build/../../src/systemd/src/libsystemd/sd-id128/sd-id128.c:274 SUMMARY: MemorySanitizer: use-of-uninitialized-value /work/build/../../src/systemd/src/journal/journal-file.c:436:13 in journal_file_init_header Exiting MS: 0 ; base unit: 0000000000000000000000000000000000000000 artifact_prefix='./'; Test unit written to ./crash-847911777b3096783f4ee70a69ab6d28380c810b [vagrant@localhost oss-fuzz]$ sudo infra/helper.py check_build --sanitizer=memory systemd Running: docker run --rm -i --privileged -e FUZZING_ENGINE=libfuzzer -e SANITIZER=memory -v /home/vagrant/oss-fuzz/build/out/systemd:/out -t gcr.io/oss-fuzz-base/base-runner test_all INFO: performing bad build checks for /out/fuzz-dhcp-server. INFO: performing bad build checks for /out/fuzz-journal-remote. INFO: performing bad build checks for /out/fuzz-unit-file. INFO: performing bad build checks for /out/fuzz-dns-packet. 4 fuzzers total, 0 seem to be broken (0%). Check build passed. It's a false positive which is most likely caused by google/sanitizers#852. I think it could be got around by avoiding `getrandom` when the code is compiled with `msan`

Previously the enumerate() callback defined for each unit type would do two things: 1. It would create perpetual units (i.e. -.slice, system.slice, -.mount and init.scope) 2. It would enumerate units from /proc/self/mountinfo, /proc/swaps and the udev database With this change these two parts are split into two seperate methods: enumerate() now only does #2, while enumerate_perpetual() is responsible for #1. Why make this change? Well, perpetual units should have a slightly different effect that those found through enumeration: as perpetual units should be up unconditionally, perpetually and thus never change state, they should also not pull in deps by their state changing, not even when the state is first set to active. Thus, their state is generally initialized through the per-device coldplug() method in similar fashion to the deserialized state from a previous run would be put into place. OTOH units found through regular enumeration should result in state changes (and thus pull in deps due to state changes), hence their state should be put in effect in the catchup() method instead. Hence, given this difference, let's also separate the functions, so that the rule is: 1. What is created in enumerate_perpetual() should be started in coldplug() 2. What is created in enumerate() should be started in catchup().

This function returns 0 on success and a negative value on failure. On success, it writes the parsed action to the address passed in its third argument. `bus_set_transient_emergency_action` does this: r = parse_emergency_action(s, system, &v); if (v < 0) // handle failure However, `v` is not updated if the function fails, and this should be checking `r` instead of `v`. The result of this is that if an invalid failure (or success) action is specified, systemd ends up creating the unit anyway and then misbehaves if it tries to run the failure action because the action value comes from uninitialized stack data. In my case, this resulted in a failed assertion: Program received signal SIGABRT, Aborted. 0x00007fe52cca0d7f in raise () from /snap/usr/lib/libc.so.6 (gdb) bt #0 0x00007fe52cca0d7f in raise () from /snap/usr/lib/libc.so.6 #1 0x00007fe52cc8b672 in abort () from /snap/usr/lib/libc.so.6 #2 0x00007fe52d66f169 in log_assert_failed_realm (realm=LOG_REALM_SYSTEMD, text=0x56177ab8e000 "action < _EMERGENCY_ACTION_MAX", file=0x56177ab8dfb8 "../src/core/emergency-action.c", line=33, func=0x56177ab8e2b0 <__PRETTY_FUNCTION__.14207> "emergency_action") at ../src/basic/log.c:795 #3 0x000056177aa98cf4 in emergency_action (m=0x56177c992cb0, action=2059118610, options=(unknown: 0), reboot_arg=0x0, exit_status=1, reason=0x7ffdd2df4290 "unit run-u0.service failed") at ../src/core/emergency-action.c:33 #4 0x000056177ab2b739 in unit_notify (u=0x56177c9eb340, os=UNIT_ACTIVE, ns=UNIT_FAILED, flags=(unknown: 0)) at ../src/core/unit.c:2504 #5 0x000056177aaf62ed in service_set_state (s=0x56177c9eb340, state=SERVICE_FAILED) at ../src/core/service.c:1104 #6 0x000056177aaf8a29 in service_enter_dead (s=0x56177c9eb340, f=SERVICE_SUCCESS, allow_restart=true) at ../src/core/service.c:1712 #7 0x000056177aaf9233 in service_enter_signal (s=0x56177c9eb340, state=SERVICE_FINAL_SIGKILL, f=SERVICE_SUCCESS) at ../src/core/service.c:1854 #8 0x000056177aaf921b in service_enter_signal (s=0x56177c9eb340, state=SERVICE_FINAL_SIGTERM, f=SERVICE_SUCCESS) at ../src/core/service.c:1852 #9 0x000056177aaf8eb3 in service_enter_stop_post (s=0x56177c9eb340, f=SERVICE_SUCCESS) at ../src/core/service.c:1788 #10 0x000056177aaf91eb in service_enter_signal (s=0x56177c9eb340, state=SERVICE_STOP_SIGKILL, f=SERVICE_SUCCESS) at ../src/core/service.c:1850 #11 0x000056177aaf91bc in service_enter_signal (s=0x56177c9eb340, state=SERVICE_STOP_SIGTERM, f=SERVICE_FAILURE_EXIT_CODE) at ../src/core/service.c:1848 #12 0x000056177aaf9759 in service_enter_running (s=0x56177c9eb340, f=SERVICE_FAILURE_EXIT_CODE) at ../src/core/service.c:1941 #13 0x000056177ab005b7 in service_sigchld_event (u=0x56177c9eb340, pid=112, code=1, status=1) at ../src/core/service.c:3296 #14 0x000056177aad84b5 in manager_invoke_sigchld_event (m=0x56177c992cb0, u=0x56177c9eb340, si=0x7ffdd2df48f0) at ../src/core/manager.c:2444 #15 0x000056177aad88df in manager_dispatch_sigchld (source=0x56177c994710, userdata=0x56177c992cb0) at ../src/core/manager.c:2508 #16 0x00007fe52d72f807 in source_dispatch (s=0x56177c994710) at ../src/libsystemd/sd-event/sd-event.c:2846 #17 0x00007fe52d730f7d in sd_event_dispatch (e=0x56177c993530) at ../src/libsystemd/sd-event/sd-event.c:3229 #18 0x00007fe52d73142e in sd_event_run (e=0x56177c993530, timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3286 #19 0x000056177aad9f71 in manager_loop (m=0x56177c992cb0) at ../src/core/manager.c:2906 #20 0x000056177aa7c876 in invoke_main_loop (m=0x56177c992cb0, ret_reexecute=0x7ffdd2df4bff, ret_retval=0x7ffdd2df4c04, ret_shutdown_verb=0x7ffdd2df4c58, ret_fds=0x7ffdd2df4c70, ret_switch_root_dir=0x7ffdd2df4c48, ret_switch_root_init=0x7ffdd2df4c50, ret_error_message=0x7ffdd2df4c60) at ../src/core/main.c:1792 #21 0x000056177aa7f251 in main (argc=2, argv=0x7ffdd2df4e78) at ../src/core/main.c:2573 Fix this by checking the correct variable. (cherry picked from commit db2df55)

This function returns 0 on success and a negative value on failure. On success, it writes the parsed action to the address passed in its third argument. `bus_set_transient_emergency_action` does this: r = parse_emergency_action(s, system, &v); if (v < 0) // handle failure However, `v` is not updated if the function fails, and this should be checking `r` instead of `v`. The result of this is that if an invalid failure (or success) action is specified, systemd ends up creating the unit anyway and then misbehaves if it tries to run the failure action because the action value comes from uninitialized stack data. In my case, this resulted in a failed assertion: Program received signal SIGABRT, Aborted. 0x00007fe52cca0d7f in raise () from /snap/usr/lib/libc.so.6 (gdb) bt #0 0x00007fe52cca0d7f in raise () from /snap/usr/lib/libc.so.6 #1 0x00007fe52cc8b672 in abort () from /snap/usr/lib/libc.so.6 #2 0x00007fe52d66f169 in log_assert_failed_realm (realm=LOG_REALM_SYSTEMD, text=0x56177ab8e000 "action < _EMERGENCY_ACTION_MAX", file=0x56177ab8dfb8 "../src/core/emergency-action.c", line=33, func=0x56177ab8e2b0 <__PRETTY_FUNCTION__.14207> "emergency_action") at ../src/basic/log.c:795 #3 0x000056177aa98cf4 in emergency_action (m=0x56177c992cb0, action=2059118610, options=(unknown: 0), reboot_arg=0x0, exit_status=1, reason=0x7ffdd2df4290 "unit run-u0.service failed") at ../src/core/emergency-action.c:33 #4 0x000056177ab2b739 in unit_notify (u=0x56177c9eb340, os=UNIT_ACTIVE, ns=UNIT_FAILED, flags=(unknown: 0)) at ../src/core/unit.c:2504 #5 0x000056177aaf62ed in service_set_state (s=0x56177c9eb340, state=SERVICE_FAILED) at ../src/core/service.c:1104 #6 0x000056177aaf8a29 in service_enter_dead (s=0x56177c9eb340, f=SERVICE_SUCCESS, allow_restart=true) at ../src/core/service.c:1712 #7 0x000056177aaf9233 in service_enter_signal (s=0x56177c9eb340, state=SERVICE_FINAL_SIGKILL, f=SERVICE_SUCCESS) at ../src/core/service.c:1854 #8 0x000056177aaf921b in service_enter_signal (s=0x56177c9eb340, state=SERVICE_FINAL_SIGTERM, f=SERVICE_SUCCESS) at ../src/core/service.c:1852 #9 0x000056177aaf8eb3 in service_enter_stop_post (s=0x56177c9eb340, f=SERVICE_SUCCESS) at ../src/core/service.c:1788 #10 0x000056177aaf91eb in service_enter_signal (s=0x56177c9eb340, state=SERVICE_STOP_SIGKILL, f=SERVICE_SUCCESS) at ../src/core/service.c:1850 #11 0x000056177aaf91bc in service_enter_signal (s=0x56177c9eb340, state=SERVICE_STOP_SIGTERM, f=SERVICE_FAILURE_EXIT_CODE) at ../src/core/service.c:1848 #12 0x000056177aaf9759 in service_enter_running (s=0x56177c9eb340, f=SERVICE_FAILURE_EXIT_CODE) at ../src/core/service.c:1941 #13 0x000056177ab005b7 in service_sigchld_event (u=0x56177c9eb340, pid=112, code=1, status=1) at ../src/core/service.c:3296 #14 0x000056177aad84b5 in manager_invoke_sigchld_event (m=0x56177c992cb0, u=0x56177c9eb340, si=0x7ffdd2df48f0) at ../src/core/manager.c:2444 #15 0x000056177aad88df in manager_dispatch_sigchld (source=0x56177c994710, userdata=0x56177c992cb0) at ../src/core/manager.c:2508 #16 0x00007fe52d72f807 in source_dispatch (s=0x56177c994710) at ../src/libsystemd/sd-event/sd-event.c:2846 #17 0x00007fe52d730f7d in sd_event_dispatch (e=0x56177c993530) at ../src/libsystemd/sd-event/sd-event.c:3229 #18 0x00007fe52d73142e in sd_event_run (e=0x56177c993530, timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3286 #19 0x000056177aad9f71 in manager_loop (m=0x56177c992cb0) at ../src/core/manager.c:2906 #20 0x000056177aa7c876 in invoke_main_loop (m=0x56177c992cb0, ret_reexecute=0x7ffdd2df4bff, ret_retval=0x7ffdd2df4c04, ret_shutdown_verb=0x7ffdd2df4c58, ret_fds=0x7ffdd2df4c70, ret_switch_root_dir=0x7ffdd2df4c48, ret_switch_root_init=0x7ffdd2df4c50, ret_error_message=0x7ffdd2df4c60) at ../src/core/main.c:1792 #21 0x000056177aa7f251 in main (argc=2, argv=0x7ffdd2df4e78) at ../src/core/main.c:2573 Fix this by checking the correct variable.

Otherwise, the test fails on Fedora 28 with ``` Jan 30 01:42:35 systemd-testsuite dbus-daemon[61]: [system] Successfully activated service 'org.freedesktop.systemd1' Jan 30 01:42:35 systemd-testsuite systemd[61]: dbus.service: Kernel keyring access prohibited, ignoring. Jan 30 01:42:35 systemd-testsuite systemd[61]: dbus.service: Executing: /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only Jan 30 01:42:50 systemd-testsuite dbus-daemon[61]: ================================================================= Jan 30 01:42:50 systemd-testsuite dbus-daemon[61]: ==61==ERROR: LeakSanitizer: detected memory leaks Jan 30 01:42:50 systemd-testsuite dbus-daemon[61]: Direct leak of 72 byte(s) in 1 object(s) allocated from: Jan 30 01:42:50 systemd-testsuite dbus-daemon[61]: #0 0x7f21f9e29088 in __interceptor_realloc (/usr/lib64/libasan.so.5+0xef088) Jan 30 01:42:50 systemd-testsuite dbus-daemon[61]: #1 0x7f21f9b1b23c (/lib64/libdbus-1.so.3+0x3323c) Jan 30 01:42:50 systemd-testsuite dbus-daemon[61]: #2 0x240000001b (<unknown module>) Jan 30 01:42:50 systemd-testsuite dbus-daemon[61]: Direct leak of 16 byte(s) in 1 object(s) allocated from: Jan 30 01:42:50 systemd-testsuite dbus-daemon[61]: #0 0x7f21f9e29088 in __interceptor_realloc (/usr/lib64/libasan.so.5+0xef088) Jan 30 01:42:50 systemd-testsuite dbus-daemon[61]: #1 0x7f21f9b1b23c (/lib64/libdbus-1.so.3+0x3323c) Jan 30 01:42:50 systemd-testsuite dbus-daemon[61]: #2 0x7ffffffff (<unknown module>) Jan 30 01:42:50 systemd-testsuite dbus-daemon[61]: SUMMARY: AddressSanitizer: 88 byte(s) leaked in 2 allocation(s). ``` The leaks were reported and fixed in https://bugs.freedesktop.org/show_bug.cgi?id=107320.

I had a test machine with ulimit -n set to 1073741816 through pam ("session required pam_limits.so set_all", which copies the limits from PID 1, left over from testing of #10921). test-execute would "hang" and then fail with a timeout when running exec-inaccessiblepaths-proc.service. It turns out that the problem was in close_all_fds(), which would go to the fallback path of doing close() 1073741813 times. Let's just fail if we hit this case. This only matters for cases where both /proc is inaccessible, and the *soft* limit has been raised. (gdb) bt #0 0x00007f7e2e73fdc8 in close () from target:/lib64/libc.so.6 #1 0x00007f7e2e42cdfd in close_nointr () from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so #2 0x00007f7e2e42d525 in close_all_fds () from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so #3 0x0000000000426e53 in exec_child () #4 0x0000000000429578 in exec_spawn () #5 0x00000000004ce1ab in service_spawn () #6 0x00000000004cff77 in service_enter_start () #7 0x00000000004d028f in service_enter_start_pre () #8 0x00000000004d16f2 in service_start () #9 0x00000000004568f4 in unit_start () #10 0x0000000000416987 in test () #11 0x0000000000417632 in test_exec_inaccessiblepaths () #12 0x0000000000419362 in run_tests () #13 0x0000000000419632 in main () (cherry picked from commit 6a461d1)

I had a test machine with ulimit -n set to 1073741816 through pam ("session required pam_limits.so set_all", which copies the limits from PID 1, left over from testing of #10921). test-execute would "hang" and then fail with a timeout when running exec-inaccessiblepaths-proc.service. It turns out that the problem was in close_all_fds(), which would go to the fallback path of doing close() 1073741813 times. Let's just fail if we hit this case. This only matters for cases where both /proc is inaccessible, and the *soft* limit has been raised. (gdb) bt #0 0x00007f7e2e73fdc8 in close () from target:/lib64/libc.so.6 #1 0x00007f7e2e42cdfd in close_nointr () from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so #2 0x00007f7e2e42d525 in close_all_fds () from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so #3 0x0000000000426e53 in exec_child () #4 0x0000000000429578 in exec_spawn () #5 0x00000000004ce1ab in service_spawn () #6 0x00000000004cff77 in service_enter_start () #7 0x00000000004d028f in service_enter_start_pre () #8 0x00000000004d16f2 in service_start () #9 0x00000000004568f4 in unit_start () #10 0x0000000000416987 in test () #11 0x0000000000417632 in test_exec_inaccessiblepaths () #12 0x0000000000419362 in run_tests () #13 0x0000000000419632 in main ()

In SecureBoot mode this is probably not what you want. As your cmdline is cryptographically signed like when using Type #2 EFI Unified Kernel Images (https://systemd.io/BOOT_LOADER_SPECIFICATION/) The user's intention is then that the cmdline should not be modified. You want to make sure that the system starts up as exactly specified in the signed artifact. (cherry picked from commit c7d26ac)

Fixes: oss-fuzz#22208 ``` test/fuzz/fuzz-calendarspec/oss-fuzz-22208... ../src/shared/calendarspec.c:666:48: runtime error: signed integer overflow: 2147000000 + 1000000 cannot be represented in type 'int' #0 0x7f0b9f6cc56a in prepend_component ../src/shared/calendarspec.c:666 #1 0x7f0b9f6cd03a in parse_chain ../src/shared/calendarspec.c:718 #2 0x7f0b9f6cea1c in parse_calendar_time ../src/shared/calendarspec.c:845 #3 0x7f0b9f6d1397 in calendar_spec_from_string ../src/shared/calendarspec.c:1084 #4 0x401570 in LLVMFuzzerTestOneInput ../src/fuzz/fuzz-calendarspec.c:17 #5 0x401ae0 in main ../src/fuzz/fuzz-main.c:39 #6 0x7f0b9e31b1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) #7 0x40122d in _start (/home/fsumsal/repos/systemd/build/fuzz-calendarspec+0x40122d) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/shared/calendarspec.c:666:48 in ``` (cherry picked from commit c07f18f)

We'd try to map a zero-byte buffer from a NULL pointer, which is undefined behaviour. src/systemd/src/libsystemd/sd-bus/bus-message.c:3161:60: runtime error: applying zero offset to null pointer #0 0x7f6ff064e691 in find_part /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3161:60 #1 0x7f6ff0640788 in message_peek_body /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3283:16 #2 0x7f6ff064e8db in enter_struct_or_dict_entry /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3967:21 #3 0x7f6ff06444ac in bus_message_enter_struct /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:4009:13 #4 0x7f6ff0641dde in sd_bus_message_enter_container /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:4136:21 #5 0x7f6ff0619874 in sd_bus_message_dump /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-dump.c:178:29 #6 0x4293d9 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-bus-message.c:39:9 #7 0x441986 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:558:15 #8 0x44121e in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:470:3 #9 0x443164 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:770:7 #10 0x4434bc in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:799:3 #11 0x42d2bc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:846:6 #12 0x42978a in main /src/libfuzzer/FuzzerMain.cpp:19:10 #13 0x7f6fef13c82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #14 0x407808 in _start (out/fuzz-bus-message+0x407808) (cherry picked from commit b17af3e)

``` p11-kit-0.23.20-1.fc32.x86_64 pam-1.3.1-26.fc33.x86_64 xz-libs-5.2.5-1.fc33.x86_64 zlib-1.2.11-21.fc32.x86_64 (gdb) bt lvalue=0x560e10 "SendOption", ltype=2, rvalue=0x560e1b "11:string", data=0x561e20, userdata=0x561cd0) at ../src/network/networkd-dhcp-common.c:580 table=0x4392e0 <network_network_gperf_lookup>, section=0x560ef0 "DHCPv4", section_line=14, lvalue=0x560e10 "SendOption", rvalue=0x560e1b "11:string", flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:132 lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, section=0x7fffffffc9f8, section_line=0x7fffffffc9a0, section_ignored=0x7fffffffc99d, l=0x560e10 "SendOption", userdata=0x561cd0) at ../src/shared/conf-parser.c:270 lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:395 lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:452 dropin_dirname=0x7fffffffcbd0 "veth99.network.d", sections=0x4f3a18 "Match", lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:511 (gdb) q A debugging session is active. Inferior 1 [process 118718] will be killed. ``` ``` $ printf '[DHCPv4]\nSendOption=1:uint8' >crash $ ./out/fuzz-network-parser ./crash INFO: Seed: 1158717610 INFO: Loaded 2 modules (199728 inline 8-bit counters): 136668 [0x7faf3e91a930, 0x7faf3e93bf0c), 63060 [0xadf190, 0xaee7e4), INFO: Loaded 2 PC tables (199728 PCs): 136668 [0x7faf3e93bf10,0x7faf3eb51cd0), 63060 [0xaee7e8,0xbe4d28), ./out/fuzz-network-parser: Running 1 inputs 1 time(s) each. Running: ./crash Assertion 's' failed at src/basic/parse-util.c:458, function int safe_atou8(const char *, uint8_t *)(). Aborting. ==5588== ERROR: libFuzzer: deadly signal #0 0x51811e in __sanitizer_print_stack_trace (/home/vagrant/systemd/out/fuzz-network-parser+0x51811e) #1 0x46b921 in fuzzer::PrintStackTrace() (/home/vagrant/systemd/out/fuzz-network-parser+0x46b921) #2 0x44ded6 in fuzzer::Fuzzer::CrashCallback() (.part.0) (/home/vagrant/systemd/out/fuzz-network-parser+0x44ded6) #3 0x44df9d in fuzzer::Fuzzer::StaticCrashSignalCallback() (/home/vagrant/systemd/out/fuzz-network-parser+0x44df9d) #4 0x7faf3d6d7b1f (/lib64/libpthread.so.0+0x14b1f) #5 0x7faf3d3c2624 in raise (/lib64/libc.so.6+0x3c624) #6 0x7faf3d3ab8d8 in abort (/lib64/libc.so.6+0x258d8) #7 0x7faf3e12593a in log_assert_failed_realm /home/vagrant/systemd/build/../src/basic/log.c:819:9 #8 0x7faf3e140ce1 in safe_atou8 /home/vagrant/systemd/build/../src/basic/parse-util.c:458:9 #9 0x68089c in config_parse_dhcp_send_option /home/vagrant/systemd/build/../src/network/networkd-dhcp-common.c:517:21 #10 0x7faf3debed4e in next_assignment /home/vagrant/systemd/build/../src/shared/conf-parser.c:132:32 #11 0x7faf3deb7783 in parse_line /home/vagrant/systemd/build/../src/shared/conf-parser.c:270:16 #12 0x7faf3deb606c in config_parse /home/vagrant/systemd/build/../src/shared/conf-parser.c:395:21 #13 0x7faf3deb85ee in config_parse_many_files /home/vagrant/systemd/build/../src/shared/conf-parser.c:452:21 #14 0x7faf3deb8c57 in config_parse_many /home/vagrant/systemd/build/../src/shared/conf-parser.c:511:16 #15 0x57c2eb in network_load_one /home/vagrant/systemd/build/../src/network/networkd-network.c:470:13 #16 0x543490 in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/network/fuzz-network-parser.c:26:16 #17 0x44e3e8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x44e3e8) #18 0x433505 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x433505) #19 0x43c449 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/out/fuzz-network-parser+0x43c449) #20 0x42c4a6 in main (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4a6) #21 0x7faf3d3ad1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) #22 0x42c4fd in _start (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4fd) NOTE: libFuzzer has rudimentary signal handlers. Combine libFuzzer with AddressSanitizer or similar for better crash reports. SUMMARY: libFuzzer: deadly signal ``` (cherry picked from commit 1eb7342) (cherry picked from commit 2a41fb2)

``` p11-kit-0.23.20-1.fc32.x86_64 pam-1.3.1-26.fc33.x86_64 xz-libs-5.2.5-1.fc33.x86_64 zlib-1.2.11-21.fc32.x86_64 (gdb) bt lvalue=0x560e10 "SendOption", ltype=2, rvalue=0x560e1b "11:string", data=0x561e20, userdata=0x561cd0) at ../src/network/networkd-dhcp-common.c:580 table=0x4392e0 <network_network_gperf_lookup>, section=0x560ef0 "DHCPv4", section_line=14, lvalue=0x560e10 "SendOption", rvalue=0x560e1b "11:string", flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:132 lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, section=0x7fffffffc9f8, section_line=0x7fffffffc9a0, section_ignored=0x7fffffffc99d, l=0x560e10 "SendOption", userdata=0x561cd0) at ../src/shared/conf-parser.c:270 lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:395 lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:452 dropin_dirname=0x7fffffffcbd0 "veth99.network.d", sections=0x4f3a18 "Match", lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:511 (gdb) q A debugging session is active. Inferior 1 [process 118718] will be killed. ``` ``` $ printf '[DHCPv4]\nSendOption=1:uint8' >crash $ ./out/fuzz-network-parser ./crash INFO: Seed: 1158717610 INFO: Loaded 2 modules (199728 inline 8-bit counters): 136668 [0x7faf3e91a930, 0x7faf3e93bf0c), 63060 [0xadf190, 0xaee7e4), INFO: Loaded 2 PC tables (199728 PCs): 136668 [0x7faf3e93bf10,0x7faf3eb51cd0), 63060 [0xaee7e8,0xbe4d28), ./out/fuzz-network-parser: Running 1 inputs 1 time(s) each. Running: ./crash Assertion 's' failed at src/basic/parse-util.c:458, function int safe_atou8(const char *, uint8_t *)(). Aborting. ==5588== ERROR: libFuzzer: deadly signal #0 0x51811e in __sanitizer_print_stack_trace (/home/vagrant/systemd/out/fuzz-network-parser+0x51811e) #1 0x46b921 in fuzzer::PrintStackTrace() (/home/vagrant/systemd/out/fuzz-network-parser+0x46b921) #2 0x44ded6 in fuzzer::Fuzzer::CrashCallback() (.part.0) (/home/vagrant/systemd/out/fuzz-network-parser+0x44ded6) #3 0x44df9d in fuzzer::Fuzzer::StaticCrashSignalCallback() (/home/vagrant/systemd/out/fuzz-network-parser+0x44df9d) #4 0x7faf3d6d7b1f (/lib64/libpthread.so.0+0x14b1f) #5 0x7faf3d3c2624 in raise (/lib64/libc.so.6+0x3c624) #6 0x7faf3d3ab8d8 in abort (/lib64/libc.so.6+0x258d8) #7 0x7faf3e12593a in log_assert_failed_realm /home/vagrant/systemd/build/../src/basic/log.c:819:9 #8 0x7faf3e140ce1 in safe_atou8 /home/vagrant/systemd/build/../src/basic/parse-util.c:458:9 #9 0x68089c in config_parse_dhcp_send_option /home/vagrant/systemd/build/../src/network/networkd-dhcp-common.c:517:21 #10 0x7faf3debed4e in next_assignment /home/vagrant/systemd/build/../src/shared/conf-parser.c:132:32 #11 0x7faf3deb7783 in parse_line /home/vagrant/systemd/build/../src/shared/conf-parser.c:270:16 #12 0x7faf3deb606c in config_parse /home/vagrant/systemd/build/../src/shared/conf-parser.c:395:21 #13 0x7faf3deb85ee in config_parse_many_files /home/vagrant/systemd/build/../src/shared/conf-parser.c:452:21 #14 0x7faf3deb8c57 in config_parse_many /home/vagrant/systemd/build/../src/shared/conf-parser.c:511:16 #15 0x57c2eb in network_load_one /home/vagrant/systemd/build/../src/network/networkd-network.c:470:13 #16 0x543490 in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/network/fuzz-network-parser.c:26:16 #17 0x44e3e8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x44e3e8) #18 0x433505 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x433505) #19 0x43c449 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/out/fuzz-network-parser+0x43c449) #20 0x42c4a6 in main (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4a6) #21 0x7faf3d3ad1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2) #22 0x42c4fd in _start (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4fd) NOTE: libFuzzer has rudimentary signal handlers. Combine libFuzzer with AddressSanitizer or similar for better crash reports. SUMMARY: libFuzzer: deadly signal ``` (cherry picked from commit 1eb7342)

C.f. 9793530. We'd crash when trying to access an already-deallocated object: Thread no. 1 (7 frames) #2 log_assert_failed_realm at ../src/basic/log.c:844 #3 event_inotify_data_drop at ../src/libsystemd/sd-event/sd-event.c:3035 #4 source_dispatch at ../src/libsystemd/sd-event/sd-event.c:3250 #5 sd_event_dispatch at ../src/libsystemd/sd-event/sd-event.c:3631 #6 sd_event_run at ../src/libsystemd/sd-event/sd-event.c:3689 #7 sd_event_loop at ../src/libsystemd/sd-event/sd-event.c:3711 #8 run at ../src/home/homed.c:47 The source in question is an inotify source, and the messages are: systemd-homed[1340]: /home/ moved or renamed, recreating watch and rescanning. systemd-homed[1340]: Assertion '*_head == _item' failed at src/libsystemd/sd-event/sd-event.c:3035, function event_inotify_data_drop(). Aborting. on_home_inotify() got called, then manager_watch_home(), which unrefs the existing inotify_event_source. I assume that the source gets dispatched again because it was still in the pending queue. I can't reproduce the issue (timing?), but this should fix #17824, https://bugzilla.redhat.com/show_bug.cgi?id=1899264. (cherry picked from commit cf53663) (cherry picked from commit 668554d)

C.f. 9793530. We'd crash when trying to access an already-deallocated object: Thread no. 1 (7 frames) #2 log_assert_failed_realm at ../src/basic/log.c:844 #3 event_inotify_data_drop at ../src/libsystemd/sd-event/sd-event.c:3035 #4 source_dispatch at ../src/libsystemd/sd-event/sd-event.c:3250 #5 sd_event_dispatch at ../src/libsystemd/sd-event/sd-event.c:3631 #6 sd_event_run at ../src/libsystemd/sd-event/sd-event.c:3689 #7 sd_event_loop at ../src/libsystemd/sd-event/sd-event.c:3711 #8 run at ../src/home/homed.c:47 The source in question is an inotify source, and the messages are: systemd-homed[1340]: /home/ moved or renamed, recreating watch and rescanning. systemd-homed[1340]: Assertion '*_head == _item' failed at src/libsystemd/sd-event/sd-event.c:3035, function event_inotify_data_drop(). Aborting. on_home_inotify() got called, then manager_watch_home(), which unrefs the existing inotify_event_source. I assume that the source gets dispatched again because it was still in the pending queue. I can't reproduce the issue (timing?), but this should fix #17824, https://bugzilla.redhat.com/show_bug.cgi?id=1899264. (cherry picked from commit cf53663)

When trying to calculate the next firing of 'Sun *-*-* 01:00:00', we'd fall into an infinite loop, because mktime() moves us "backwards": Before this patch: tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00 tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00 tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00 ... We rely on mktime() normalizing the time. The man page does not say that it'll move the time forward, but our algorithm relies on this. So let's catch this case explicitly. With this patch: $ TZ=Europe/Dublin faketime 2021-03-21 build/systemd-analyze calendar --iterations=5 'Sun *-*-* 01:00:00' Normalized form: Sun *-*-* 01:00:00 Next elapse: Sun 2021-03-21 01:00:00 GMT (in UTC): Sun 2021-03-21 01:00:00 UTC From now: 59min left Iter. #2: Sun 2021-04-04 01:00:00 IST (in UTC): Sun 2021-04-04 00:00:00 UTC From now: 1 weeks 6 days left <---- note the 2 week jump here Iter. #3: Sun 2021-04-11 01:00:00 IST (in UTC): Sun 2021-04-11 00:00:00 UTC From now: 2 weeks 6 days left Iter. #4: Sun 2021-04-18 01:00:00 IST (in UTC): Sun 2021-04-18 00:00:00 UTC From now: 3 weeks 6 days left Iter. #5: Sun 2021-04-25 01:00:00 IST (in UTC): Sun 2021-04-25 00:00:00 UTC From now: 1 months 4 days left Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1941335. (cherry picked from commit 129cb6e) (cherry picked from commit e5cf86f)

When trying to calculate the next firing of 'Sun *-*-* 01:00:00', we'd fall into an infinite loop, because mktime() moves us "backwards": Before this patch: tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00 tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00 tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00 ... We rely on mktime() normalizing the time. The man page does not say that it'll move the time forward, but our algorithm relies on this. So let's catch this case explicitly. With this patch: $ TZ=Europe/Dublin faketime 2021-03-21 build/systemd-analyze calendar --iterations=5 'Sun *-*-* 01:00:00' Normalized form: Sun *-*-* 01:00:00 Next elapse: Sun 2021-03-21 01:00:00 GMT (in UTC): Sun 2021-03-21 01:00:00 UTC From now: 59min left Iter. #2: Sun 2021-04-04 01:00:00 IST (in UTC): Sun 2021-04-04 00:00:00 UTC From now: 1 weeks 6 days left <---- note the 2 week jump here Iter. #3: Sun 2021-04-11 01:00:00 IST (in UTC): Sun 2021-04-11 00:00:00 UTC From now: 2 weeks 6 days left Iter. #4: Sun 2021-04-18 01:00:00 IST (in UTC): Sun 2021-04-18 00:00:00 UTC From now: 3 weeks 6 days left Iter. #5: Sun 2021-04-25 01:00:00 IST (in UTC): Sun 2021-04-25 00:00:00 UTC From now: 1 months 4 days left Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1941335. (cherry picked from commit 129cb6e)

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 #22033. (cherry picked from commit 5f02870)

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 #22033. (cherry picked from commit 5f02870) (cherry picked from commit d08f6ff)

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 #22033. (cherry picked from commit 5f02870) (cherry picked from commit d08f6ff) (cherry picked from commit cf6d1dc)

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 #22033.

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 ```

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 ```

================================================================= ==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)

================================================================= ==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) (cherry picked from commit 9591c0a)

================================================================= ==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) (cherry picked from commit 9591c0a) (cherry picked from commit 7dc0f80)

…stemd#2" as appropriate

``` 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) ```

Similarly to bbac11c we need to enable session lingering for the test user, so the long-running test units are not killed prematurely: [ 18.822261] testsuite-55.sh[403]: + systemctl start --machine [email protected] --user testsuite-55-testchill.service [ 18.852775] systemd[1]: Started run-u17.service. [ 19.256431] (o-bridge)[526]: pam_unix(login:session): session opened for user testuser(uid=4711) by testuser(uid=0) [ 19.288346] systemd[1]: Started session-2.scope. [ 20.165874] systemd[392]: Created slice session.slice. [ 20.166459] systemd[392]: Starting dbus-broker.service... [ 20.220189] dbus-broker-launch[529]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +31: Eavesdropping is deprecated and ignored [ 20.220189] dbus-broker-launch[529]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +33: Eavesdropping is deprecated and ignored [ 20.220494] systemd[392]: Started dbus-broker.service. [ 20.224276] dbus-broker-launch[529]: Ready [ 20.231702] systemd[392]: Created slice testsuite.slice. [ 20.231976] systemd[392]: Created slice testsuite-55.slice. [ 20.232259] systemd[392]: Created slice testsuite-55-workload.slice. [ 31.065294] testsuite-55.sh[403]: + systemctl start --machine [email protected] --user testsuite-55-testbloat.service [ 31.065641] (sd-pam)[528]: pam_unix(login:session): session closed for user testuser [ 31.066103] (sd-pam)[528]: pam_systemd(login:session): Failed to release session: Access denied [ 31.066152] systemd[392]: Started testsuite-55-testchill.service. [ 31.068062] systemd[1]: run-u17.service: Deactivated successfully. [ 31.068217] dbus-broker[389]: A security policy denied :1.20 to send method call /org/freedesktop/login1:org.freedesktop.login1.Manager.ReleaseSession to org.freedesktop.login1. [ 31.075901] (o-bridge)[537]: pam_unix(login:session): session opened for user testuser(uid=4711) by testuser(uid=0) [ 31.091098] systemd[1]: Stopping session-2.scope... [ 31.092158] systemd[1]: Started run-u21.service. [ 31.092993] systemd[1]: session-2.scope: Deactivated successfully. [ 31.093287] systemd[1]: Stopped session-2.scope. [ 31.095798] systemd[1]: Stopping [email protected]... [ 31.103541] systemd[392]: Activating special unit exit.target... [ 31.108359] systemd[392]: Stopped target default.target. [ 31.109798] systemd[392]: Stopped target timers.target. [ 31.110790] systemd[392]: Stopping testsuite-55-testchill.service... [ 31.112154] systemd[392]: Stopped testsuite-55-testchill.service. [ 31.114033] systemd[392]: Removed slice testsuite-55-workload.slice. [ 31.114971] systemd[392]: Removed slice testsuite-55.slice. [ 31.115858] systemd[392]: Removed slice testsuite.slice. ... [ 31.475949] testsuite-55.sh[403]: + systemctl --machine [email protected] --user status testsuite-55-testchill.service [ 31.490464] systemd[1]: session-3.scope: Deactivated successfully. [ 31.565929] systemd[1]: Started run-u33.service. [ 31.592437] (o-bridge)[583]: pam_unix(login:session): session opened for user testuser(uid=4711) by testuser(uid=0) [ 31.610210] systemd[1]: Started session-5.scope. [ 31.616960] testsuite-55.sh[578]: ○ testsuite-55-testchill.service - No memory pressure [ 31.616960] testsuite-55.sh[578]: Loaded: loaded (/usr/lib/systemd/tests/testdata/units/testsuite-55-testchill.service; static) [ 31.616960] testsuite-55.sh[578]: Active: inactive (dead) [ 31.617438] (sd-pam)[586]: pam_unix(login:session): session closed for user testuser Addresses systemd/systemd#31426 (comment). (cherry picked from commit ff80bd2) (cherry picked from commit 51b1a49)

Similarly to bbac11c we need to enable session lingering for the test user, so the long-running test units are not killed prematurely: [ 18.822261] testsuite-55.sh[403]: + systemctl start --machine [email protected] --user testsuite-55-testchill.service [ 18.852775] systemd[1]: Started run-u17.service. [ 19.256431] (o-bridge)[526]: pam_unix(login:session): session opened for user testuser(uid=4711) by testuser(uid=0) [ 19.288346] systemd[1]: Started session-2.scope. [ 20.165874] systemd[392]: Created slice session.slice. [ 20.166459] systemd[392]: Starting dbus-broker.service... [ 20.220189] dbus-broker-launch[529]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +31: Eavesdropping is deprecated and ignored [ 20.220189] dbus-broker-launch[529]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +33: Eavesdropping is deprecated and ignored [ 20.220494] systemd[392]: Started dbus-broker.service. [ 20.224276] dbus-broker-launch[529]: Ready [ 20.231702] systemd[392]: Created slice testsuite.slice. [ 20.231976] systemd[392]: Created slice testsuite-55.slice. [ 20.232259] systemd[392]: Created slice testsuite-55-workload.slice. [ 31.065294] testsuite-55.sh[403]: + systemctl start --machine [email protected] --user testsuite-55-testbloat.service [ 31.065641] (sd-pam)[528]: pam_unix(login:session): session closed for user testuser [ 31.066103] (sd-pam)[528]: pam_systemd(login:session): Failed to release session: Access denied [ 31.066152] systemd[392]: Started testsuite-55-testchill.service. [ 31.068062] systemd[1]: run-u17.service: Deactivated successfully. [ 31.068217] dbus-broker[389]: A security policy denied :1.20 to send method call /org/freedesktop/login1:org.freedesktop.login1.Manager.ReleaseSession to org.freedesktop.login1. [ 31.075901] (o-bridge)[537]: pam_unix(login:session): session opened for user testuser(uid=4711) by testuser(uid=0) [ 31.091098] systemd[1]: Stopping session-2.scope... [ 31.092158] systemd[1]: Started run-u21.service. [ 31.092993] systemd[1]: session-2.scope: Deactivated successfully. [ 31.093287] systemd[1]: Stopped session-2.scope. [ 31.095798] systemd[1]: Stopping [email protected]... [ 31.103541] systemd[392]: Activating special unit exit.target... [ 31.108359] systemd[392]: Stopped target default.target. [ 31.109798] systemd[392]: Stopped target timers.target. [ 31.110790] systemd[392]: Stopping testsuite-55-testchill.service... [ 31.112154] systemd[392]: Stopped testsuite-55-testchill.service. [ 31.114033] systemd[392]: Removed slice testsuite-55-workload.slice. [ 31.114971] systemd[392]: Removed slice testsuite-55.slice. [ 31.115858] systemd[392]: Removed slice testsuite.slice. ... [ 31.475949] testsuite-55.sh[403]: + systemctl --machine [email protected] --user status testsuite-55-testchill.service [ 31.490464] systemd[1]: session-3.scope: Deactivated successfully. [ 31.565929] systemd[1]: Started run-u33.service. [ 31.592437] (o-bridge)[583]: pam_unix(login:session): session opened for user testuser(uid=4711) by testuser(uid=0) [ 31.610210] systemd[1]: Started session-5.scope. [ 31.616960] testsuite-55.sh[578]: ○ testsuite-55-testchill.service - No memory pressure [ 31.616960] testsuite-55.sh[578]: Loaded: loaded (/usr/lib/systemd/tests/testdata/units/testsuite-55-testchill.service; static) [ 31.616960] testsuite-55.sh[578]: Active: inactive (dead) [ 31.617438] (sd-pam)[586]: pam_unix(login:session): session closed for user testuser Addresses systemd/systemd#31426 (comment). (cherry picked from commit ff80bd2) (cherry picked from commit 51b1a49) (cherry picked from commit e6db5ac)

Similarly to bbac11c we need to enable session lingering for the test user, so the long-running test units are not killed prematurely: [ 18.822261] testsuite-55.sh[403]: + systemctl start --machine [email protected] --user testsuite-55-testchill.service [ 18.852775] systemd[1]: Started run-u17.service. [ 19.256431] (o-bridge)[526]: pam_unix(login:session): session opened for user testuser(uid=4711) by testuser(uid=0) [ 19.288346] systemd[1]: Started session-2.scope. [ 20.165874] systemd[392]: Created slice session.slice. [ 20.166459] systemd[392]: Starting dbus-broker.service... [ 20.220189] dbus-broker-launch[529]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +31: Eavesdropping is deprecated and ignored [ 20.220189] dbus-broker-launch[529]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +33: Eavesdropping is deprecated and ignored [ 20.220494] systemd[392]: Started dbus-broker.service. [ 20.224276] dbus-broker-launch[529]: Ready [ 20.231702] systemd[392]: Created slice testsuite.slice. [ 20.231976] systemd[392]: Created slice testsuite-55.slice. [ 20.232259] systemd[392]: Created slice testsuite-55-workload.slice. [ 31.065294] testsuite-55.sh[403]: + systemctl start --machine [email protected] --user testsuite-55-testbloat.service [ 31.065641] (sd-pam)[528]: pam_unix(login:session): session closed for user testuser [ 31.066103] (sd-pam)[528]: pam_systemd(login:session): Failed to release session: Access denied [ 31.066152] systemd[392]: Started testsuite-55-testchill.service. [ 31.068062] systemd[1]: run-u17.service: Deactivated successfully. [ 31.068217] dbus-broker[389]: A security policy denied :1.20 to send method call /org/freedesktop/login1:org.freedesktop.login1.Manager.ReleaseSession to org.freedesktop.login1. [ 31.075901] (o-bridge)[537]: pam_unix(login:session): session opened for user testuser(uid=4711) by testuser(uid=0) [ 31.091098] systemd[1]: Stopping session-2.scope... [ 31.092158] systemd[1]: Started run-u21.service. [ 31.092993] systemd[1]: session-2.scope: Deactivated successfully. [ 31.093287] systemd[1]: Stopped session-2.scope. [ 31.095798] systemd[1]: Stopping [email protected]... [ 31.103541] systemd[392]: Activating special unit exit.target... [ 31.108359] systemd[392]: Stopped target default.target. [ 31.109798] systemd[392]: Stopped target timers.target. [ 31.110790] systemd[392]: Stopping testsuite-55-testchill.service... [ 31.112154] systemd[392]: Stopped testsuite-55-testchill.service. [ 31.114033] systemd[392]: Removed slice testsuite-55-workload.slice. [ 31.114971] systemd[392]: Removed slice testsuite-55.slice. [ 31.115858] systemd[392]: Removed slice testsuite.slice. ... [ 31.475949] testsuite-55.sh[403]: + systemctl --machine [email protected] --user status testsuite-55-testchill.service [ 31.490464] systemd[1]: session-3.scope: Deactivated successfully. [ 31.565929] systemd[1]: Started run-u33.service. [ 31.592437] (o-bridge)[583]: pam_unix(login:session): session opened for user testuser(uid=4711) by testuser(uid=0) [ 31.610210] systemd[1]: Started session-5.scope. [ 31.616960] testsuite-55.sh[578]: ○ testsuite-55-testchill.service - No memory pressure [ 31.616960] testsuite-55.sh[578]: Loaded: loaded (/usr/lib/systemd/tests/testdata/units/testsuite-55-testchill.service; static) [ 31.616960] testsuite-55.sh[578]: Active: inactive (dead) [ 31.617438] (sd-pam)[586]: pam_unix(login:session): session closed for user testuser Addresses systemd/systemd#31426 (comment). (cherry picked from commit ff80bd2) (cherry picked from commit 51b1a49) (cherry picked from commit e6db5ac) (cherry picked from commit 026edfe)

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 (cherry picked from commit 842a674) (cherry picked from commit b342fb5)

When trying to calculate the next firing of 'hourly', we'd lose the tm_isdst value on the next iteration. On most systems in Europe/Dublin it would cause a 100% cpu hang due to timers restarting. This happens in Europe/Dublin because Ireland defines the Irish Standard Time as UTC+1, so winter time is encoded in tzdata as negative 1 hour of daylight saving. Before this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration systemd#2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration systemd#3: Sun 2025-03-30 00:00:00 GMT <-- note every next iteration having the same firing time (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago ... With this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration systemd#2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration systemd#3: Sun 2025-03-30 02:00:00 IST <-- the expected 1 hour jump (in UTC): Sun 2025-03-30 01:00:00 UTC From now: 11h ago ... This bug isn't reproduced on Debian and Ubuntu because they mitigate it by using the rearguard version of tzdata. ArchLinux and NixOS don't, so it would cause pid1 to spin during DST transition. This is how the affected tzdata looks like: $ zdump -V -c 2024,2025 Europe/Dublin Europe/Dublin Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=1 gmtoff=0 Europe/Dublin Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=1 gmtoff=0 Compare it to Europe/London: $ zdump -V -c 2024,2025 Europe/London Europe/London Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=0 gmtoff=0 Europe/London Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=0 gmtoff=0 Fixes #32039. (cherry picked from commit e4bb033) (cherry picked from commit 07c01efc82d4a239ef0d14da54d36053294ad203) There were some conflicts related to the skipping of 6f5cf41, but the tests pass with and the example output above also looks good, so I think the backport is correct. (cherry picked from commit 1568dea89ebb84ed2c9cf8c45aaf90c07858cbc0)

When trying to calculate the next firing of 'hourly', we'd lose the tm_isdst value on the next iteration. On most systems in Europe/Dublin it would cause a 100% cpu hang due to timers restarting. This happens in Europe/Dublin because Ireland defines the Irish Standard Time as UTC+1, so winter time is encoded in tzdata as negative 1 hour of daylight saving. Before this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration #2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration #3: Sun 2025-03-30 00:00:00 GMT <-- note every next iteration having the same firing time (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago ... With this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration #2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration #3: Sun 2025-03-30 02:00:00 IST <-- the expected 1 hour jump (in UTC): Sun 2025-03-30 01:00:00 UTC From now: 11h ago ... This bug isn't reproduced on Debian and Ubuntu because they mitigate it by using the rearguard version of tzdata. ArchLinux and NixOS don't, so it would cause pid1 to spin during DST transition. This is how the affected tzdata looks like: $ zdump -V -c 2024,2025 Europe/Dublin Europe/Dublin Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=1 gmtoff=0 Europe/Dublin Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=1 gmtoff=0 Compare it to Europe/London: $ zdump -V -c 2024,2025 Europe/London Europe/London Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=0 gmtoff=0 Europe/London Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=0 gmtoff=0 Fixes #32039. (cherry picked from commit e4bb033) (cherry picked from commit 07c01efc82d4a239ef0d14da54d36053294ad203) There were some conflicts related to the skipping of 6f5cf41, but the tests pass with and the example output above also looks good, so I think the backport is correct. (cherry picked from commit 1568dea89ebb84ed2c9cf8c45aaf90c07858cbc0)

When trying to calculate the next firing of 'hourly', we'd lose the tm_isdst value on the next iteration. On most systems in Europe/Dublin it would cause a 100% cpu hang due to timers restarting. This happens in Europe/Dublin because Ireland defines the Irish Standard Time as UTC+1, so winter time is encoded in tzdata as negative 1 hour of daylight saving. Before this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration systemd#2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration systemd#3: Sun 2025-03-30 00:00:00 GMT <-- note every next iteration having the same firing time (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago ... With this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration systemd#2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration systemd#3: Sun 2025-03-30 02:00:00 IST <-- the expected 1 hour jump (in UTC): Sun 2025-03-30 01:00:00 UTC From now: 11h ago ... This bug isn't reproduced on Debian and Ubuntu because they mitigate it by using the rearguard version of tzdata. ArchLinux and NixOS don't, so it would cause pid1 to spin during DST transition. This is how the affected tzdata looks like: $ zdump -V -c 2024,2025 Europe/Dublin Europe/Dublin Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=1 gmtoff=0 Europe/Dublin Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=1 gmtoff=0 Compare it to Europe/London: $ zdump -V -c 2024,2025 Europe/London Europe/London Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=0 gmtoff=0 Europe/London Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=0 gmtoff=0 Fixes #32039. (cherry picked from commit e4bb033) (cherry picked from commit 07c01efc82d4a239ef0d14da54d36053294ad203) There were some conflicts related to the skipping of 6f5cf41, but the tests pass with and the example output above also looks good, so I think the backport is correct. (cherry picked from commit 1568dea89ebb84ed2c9cf8c45aaf90c07858cbc0) (cherry picked from commit f3dc34e)

When trying to calculate the next firing of 'hourly', we'd lose the tm_isdst value on the next iteration. On most systems in Europe/Dublin it would cause a 100% cpu hang due to timers restarting. This happens in Europe/Dublin because Ireland defines the Irish Standard Time as UTC+1, so winter time is encoded in tzdata as negative 1 hour of daylight saving. Before this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration #2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration #3: Sun 2025-03-30 00:00:00 GMT <-- note every next iteration having the same firing time (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago ... With this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration #2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration #3: Sun 2025-03-30 02:00:00 IST <-- the expected 1 hour jump (in UTC): Sun 2025-03-30 01:00:00 UTC From now: 11h ago ... This bug isn't reproduced on Debian and Ubuntu because they mitigate it by using the rearguard version of tzdata. ArchLinux and NixOS don't, so it would cause pid1 to spin during DST transition. This is how the affected tzdata looks like: $ zdump -V -c 2024,2025 Europe/Dublin Europe/Dublin Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=1 gmtoff=0 Europe/Dublin Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=1 gmtoff=0 Compare it to Europe/London: $ zdump -V -c 2024,2025 Europe/London Europe/London Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=0 gmtoff=0 Europe/London Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=0 gmtoff=0 Fixes #32039. (cherry picked from commit e4bb033) (cherry picked from commit 07c01efc82d4a239ef0d14da54d36053294ad203) There were some conflicts related to the skipping of 6f5cf41, but the tests pass with and the example output above also looks good, so I think the backport is correct. (cherry picked from commit 1568dea89ebb84ed2c9cf8c45aaf90c07858cbc0) (cherry picked from commit f3dc34e)

When trying to calculate the next firing of 'hourly', we'd lose the tm_isdst value on the next iteration. On most systems in Europe/Dublin it would cause a 100% cpu hang due to timers restarting. This happens in Europe/Dublin because Ireland defines the Irish Standard Time as UTC+1, so winter time is encoded in tzdata as negative 1 hour of daylight saving. Before this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration systemd#2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration systemd#3: Sun 2025-03-30 00:00:00 GMT <-- note every next iteration having the same firing time (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago ... With this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration systemd#2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration systemd#3: Sun 2025-03-30 02:00:00 IST <-- the expected 1 hour jump (in UTC): Sun 2025-03-30 01:00:00 UTC From now: 11h ago ... This bug isn't reproduced on Debian and Ubuntu because they mitigate it by using the rearguard version of tzdata. ArchLinux and NixOS don't, so it would cause pid1 to spin during DST transition. This is how the affected tzdata looks like: $ zdump -V -c 2024,2025 Europe/Dublin Europe/Dublin Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=1 gmtoff=0 Europe/Dublin Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=1 gmtoff=0 Compare it to Europe/London: $ zdump -V -c 2024,2025 Europe/London Europe/London Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=0 gmtoff=0 Europe/London Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=0 gmtoff=0 Fixes #32039. (cherry picked from commit e4bb033) (cherry picked from commit 07c01efc82d4a239ef0d14da54d36053294ad203) There were some conflicts related to the skipping of 6f5cf41, but the tests pass with and the example output above also looks good, so I think the backport is correct. (cherry picked from commit 1568dea89ebb84ed2c9cf8c45aaf90c07858cbc0) (cherry picked from commit f3dc34e) (cherry picked from commit 2230a5d)

When trying to calculate the next firing of 'hourly', we'd lose the tm_isdst value on the next iteration. On most systems in Europe/Dublin it would cause a 100% cpu hang due to timers restarting. This happens in Europe/Dublin because Ireland defines the Irish Standard Time as UTC+1, so winter time is encoded in tzdata as negative 1 hour of daylight saving. Before this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration #2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration #3: Sun 2025-03-30 00:00:00 GMT <-- note every next iteration having the same firing time (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago ... With this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration #2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration #3: Sun 2025-03-30 02:00:00 IST <-- the expected 1 hour jump (in UTC): Sun 2025-03-30 01:00:00 UTC From now: 11h ago ... This bug isn't reproduced on Debian and Ubuntu because they mitigate it by using the rearguard version of tzdata. ArchLinux and NixOS don't, so it would cause pid1 to spin during DST transition. This is how the affected tzdata looks like: $ zdump -V -c 2024,2025 Europe/Dublin Europe/Dublin Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=1 gmtoff=0 Europe/Dublin Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=1 gmtoff=0 Compare it to Europe/London: $ zdump -V -c 2024,2025 Europe/London Europe/London Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=0 gmtoff=0 Europe/London Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=0 gmtoff=0 Fixes #32039. (cherry picked from commit e4bb033) (cherry picked from commit 07c01efc82d4a239ef0d14da54d36053294ad203) There were some conflicts related to the skipping of 6f5cf41, but the tests pass with and the example output above also looks good, so I think the backport is correct. (cherry picked from commit 1568dea89ebb84ed2c9cf8c45aaf90c07858cbc0) (cherry picked from commit f3dc34e) (cherry picked from commit 2230a5d)

When trying to calculate the next firing of 'hourly', we'd lose the tm_isdst value on the next iteration. On most systems in Europe/Dublin it would cause a 100% cpu hang due to timers restarting. This happens in Europe/Dublin because Ireland defines the Irish Standard Time as UTC+1, so winter time is encoded in tzdata as negative 1 hour of daylight saving. Before this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration systemd#2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration systemd#3: Sun 2025-03-30 00:00:00 GMT <-- note every next iteration having the same firing time (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago ... With this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration systemd#2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration systemd#3: Sun 2025-03-30 02:00:00 IST <-- the expected 1 hour jump (in UTC): Sun 2025-03-30 01:00:00 UTC From now: 11h ago ... This bug isn't reproduced on Debian and Ubuntu because they mitigate it by using the rearguard version of tzdata. ArchLinux and NixOS don't, so it would cause pid1 to spin during DST transition. This is how the affected tzdata looks like: $ zdump -V -c 2024,2025 Europe/Dublin Europe/Dublin Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=1 gmtoff=0 Europe/Dublin Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=1 gmtoff=0 Compare it to Europe/London: $ zdump -V -c 2024,2025 Europe/London Europe/London Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=0 gmtoff=0 Europe/London Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=0 gmtoff=0 Fixes #32039. (cherry picked from commit e4bb033) (cherry picked from commit 07c01efc82d4a239ef0d14da54d36053294ad203) There were some conflicts related to the skipping of 6f5cf41, but the tests pass with and the example output above also looks good, so I think the backport is correct. (cherry picked from commit 1568dea89ebb84ed2c9cf8c45aaf90c07858cbc0) (cherry picked from commit f3dc34e) (cherry picked from commit 2230a5d) (cherry picked from commit 8c08ad7)

When trying to calculate the next firing of 'hourly', we'd lose the tm_isdst value on the next iteration. On most systems in Europe/Dublin it would cause a 100% cpu hang due to timers restarting. This happens in Europe/Dublin because Ireland defines the Irish Standard Time as UTC+1, so winter time is encoded in tzdata as negative 1 hour of daylight saving. Before this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration #2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration #3: Sun 2025-03-30 00:00:00 GMT <-- note every next iteration having the same firing time (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago ... With this patch: $ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly' Original form: hourly Normalized form: *-*-* *:00:00 Next elapse: Sat 2025-03-29 23:00:00 GMT (in UTC): Sat 2025-03-29 23:00:00 UTC From now: 13h ago Iteration #2: Sun 2025-03-30 00:00:00 GMT (in UTC): Sun 2025-03-30 00:00:00 UTC From now: 12h ago Iteration #3: Sun 2025-03-30 02:00:00 IST <-- the expected 1 hour jump (in UTC): Sun 2025-03-30 01:00:00 UTC From now: 11h ago ... This bug isn't reproduced on Debian and Ubuntu because they mitigate it by using the rearguard version of tzdata. ArchLinux and NixOS don't, so it would cause pid1 to spin during DST transition. This is how the affected tzdata looks like: $ zdump -V -c 2024,2025 Europe/Dublin Europe/Dublin Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=1 gmtoff=0 Europe/Dublin Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 IST isdst=0 gmtoff=3600 Europe/Dublin Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=1 gmtoff=0 Compare it to Europe/London: $ zdump -V -c 2024,2025 Europe/London Europe/London Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=0 gmtoff=0 Europe/London Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 BST isdst=1 gmtoff=3600 Europe/London Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=0 gmtoff=0 Fixes #32039. (cherry picked from commit e4bb033) (cherry picked from commit 07c01efc82d4a239ef0d14da54d36053294ad203) There were some conflicts related to the skipping of 6f5cf41, but the tests pass with and the example output above also looks good, so I think the backport is correct. (cherry picked from commit 1568dea89ebb84ed2c9cf8c45aaf90c07858cbc0) (cherry picked from commit f3dc34e) (cherry picked from commit 2230a5d) (cherry picked from commit 8c08ad7)

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) systemd#1 0x7fa51f128325 (/lib64/libxkbcommon.so.0+0x1c325) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#2 0x7fa51f121952 (/lib64/libxkbcommon.so.0+0x15952) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#3 0x7fa51f123d3a (/lib64/libxkbcommon.so.0+0x17d3a) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#4 0x7fa51f117c86 (/lib64/libxkbcommon.so.0+0xbc86) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#5 0x7fa51f12548f (/lib64/libxkbcommon.so.0+0x1948f) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#6 0x7fa51f125c9e (/lib64/libxkbcommon.so.0+0x19c9e) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#7 0x7fa51f126a59 (/lib64/libxkbcommon.so.0+0x1aa59) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#8 0x7fa51f12cec6 (/lib64/libxkbcommon.so.0+0x20ec6) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#9 0x7fa51f12e3c2 (/lib64/libxkbcommon.so.0+0x223c2) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#10 0x7fa51f12a4e5 in xkb_keymap_new_from_names (/lib64/libxkbcommon.so.0+0x1e4e5) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#11 0x5574dd63f864 in verify_xkb_rmlvo /usr/src/debug/systemd/src/locale/xkbcommon-util.c:69:14 (snip) ``` (cherry picked from commit 1860990) (cherry picked from commit 5d7d60b8dd01282adbe89084b479a51aaff4cf47) (cherry picked from commit 0c27a6f4b40d0e888cd93aa6120e379c88b8e0c4)

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) ``` (cherry picked from commit 1860990) (cherry picked from commit 5d7d60b8dd01282adbe89084b479a51aaff4cf47) (cherry picked from commit 0c27a6f4b40d0e888cd93aa6120e379c88b8e0c4)

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) systemd#1 0x7fa51f128325 (/lib64/libxkbcommon.so.0+0x1c325) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#2 0x7fa51f121952 (/lib64/libxkbcommon.so.0+0x15952) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#3 0x7fa51f123d3a (/lib64/libxkbcommon.so.0+0x17d3a) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#4 0x7fa51f117c86 (/lib64/libxkbcommon.so.0+0xbc86) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#5 0x7fa51f12548f (/lib64/libxkbcommon.so.0+0x1948f) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#6 0x7fa51f125c9e (/lib64/libxkbcommon.so.0+0x19c9e) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#7 0x7fa51f126a59 (/lib64/libxkbcommon.so.0+0x1aa59) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#8 0x7fa51f12cec6 (/lib64/libxkbcommon.so.0+0x20ec6) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#9 0x7fa51f12e3c2 (/lib64/libxkbcommon.so.0+0x223c2) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#10 0x7fa51f12a4e5 in xkb_keymap_new_from_names (/lib64/libxkbcommon.so.0+0x1e4e5) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#11 0x5574dd63f864 in verify_xkb_rmlvo /usr/src/debug/systemd/src/locale/xkbcommon-util.c:69:14 (snip) ``` (cherry picked from commit 1860990) (cherry picked from commit 5d7d60b8dd01282adbe89084b479a51aaff4cf47) (cherry picked from commit 0c27a6f4b40d0e888cd93aa6120e379c88b8e0c4) (cherry picked from commit 630ed0c)

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) ``` (cherry picked from commit 1860990) (cherry picked from commit 5d7d60b8dd01282adbe89084b479a51aaff4cf47) (cherry picked from commit 0c27a6f4b40d0e888cd93aa6120e379c88b8e0c4) (cherry picked from commit 630ed0c)

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) systemd#1 0x00007ff86bb4965f __libc_fork (libc.so.6 + 0xd465f) systemd#2 0x000055e88011b0ad make_child (bash + 0x550ad) systemd#3 0x000055e8800fd05f n/a (bash + 0x3705f) systemd#4 0x000055e880100116 execute_command_internal (bash + 0x3a116) systemd#5 0x000055e8801011f2 execute_command_internal (bash + 0x3b1f2) systemd#6 0x000055e8801025b6 execute_command (bash + 0x3c5b6) systemd#7 0x000055e8800f134b reader_loop (bash + 0x2b34b) systemd#8 0x000055e8800e757d main (bash + 0x2157d) systemd#9 0x00007ff86ba98850 n/a (libc.so.6 + 0x23850) systemd#10 0x00007ff86ba9890a __libc_start_main (libc.so.6 + 0x2390a) systemd#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 - (cherry picked from commit 1326d2d)

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) systemd#1 0x7fa51f128325 (/lib64/libxkbcommon.so.0+0x1c325) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#2 0x7fa51f121952 (/lib64/libxkbcommon.so.0+0x15952) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#3 0x7fa51f123d3a (/lib64/libxkbcommon.so.0+0x17d3a) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#4 0x7fa51f117c86 (/lib64/libxkbcommon.so.0+0xbc86) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#5 0x7fa51f12548f (/lib64/libxkbcommon.so.0+0x1948f) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#6 0x7fa51f125c9e (/lib64/libxkbcommon.so.0+0x19c9e) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#7 0x7fa51f126a59 (/lib64/libxkbcommon.so.0+0x1aa59) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#8 0x7fa51f12cec6 (/lib64/libxkbcommon.so.0+0x20ec6) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#9 0x7fa51f12e3c2 (/lib64/libxkbcommon.so.0+0x223c2) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#10 0x7fa51f12a4e5 in xkb_keymap_new_from_names (/lib64/libxkbcommon.so.0+0x1e4e5) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#11 0x5574dd63f864 in verify_xkb_rmlvo /usr/src/debug/systemd/src/locale/xkbcommon-util.c:69:14 (snip) ``` (cherry picked from commit 1860990) (cherry picked from commit 5d7d60b8dd01282adbe89084b479a51aaff4cf47) (cherry picked from commit 0c27a6f4b40d0e888cd93aa6120e379c88b8e0c4) (cherry picked from commit 630ed0c) (cherry picked from commit 7b1259f)

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 - (cherry picked from commit 1326d2d)

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) ``` (cherry picked from commit 1860990) (cherry picked from commit 5d7d60b8dd01282adbe89084b479a51aaff4cf47) (cherry picked from commit 0c27a6f4b40d0e888cd93aa6120e379c88b8e0c4) (cherry picked from commit 630ed0c) (cherry picked from commit 7b1259f)

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) systemd#1 0x00007ff86bb4965f __libc_fork (libc.so.6 + 0xd465f) systemd#2 0x000055e88011b0ad make_child (bash + 0x550ad) systemd#3 0x000055e8800fd05f n/a (bash + 0x3705f) systemd#4 0x000055e880100116 execute_command_internal (bash + 0x3a116) systemd#5 0x000055e8801011f2 execute_command_internal (bash + 0x3b1f2) systemd#6 0x000055e8801025b6 execute_command (bash + 0x3c5b6) systemd#7 0x000055e8800f134b reader_loop (bash + 0x2b34b) systemd#8 0x000055e8800e757d main (bash + 0x2157d) systemd#9 0x00007ff86ba98850 n/a (libc.so.6 + 0x23850) systemd#10 0x00007ff86ba9890a __libc_start_main (libc.so.6 + 0x2390a) systemd#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 - (cherry picked from commit 1326d2d) (cherry picked from commit de5f0a3)

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) systemd#1 0x7fa51f128325 (/lib64/libxkbcommon.so.0+0x1c325) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#2 0x7fa51f121952 (/lib64/libxkbcommon.so.0+0x15952) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#3 0x7fa51f123d3a (/lib64/libxkbcommon.so.0+0x17d3a) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#4 0x7fa51f117c86 (/lib64/libxkbcommon.so.0+0xbc86) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#5 0x7fa51f12548f (/lib64/libxkbcommon.so.0+0x1948f) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#6 0x7fa51f125c9e (/lib64/libxkbcommon.so.0+0x19c9e) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#7 0x7fa51f126a59 (/lib64/libxkbcommon.so.0+0x1aa59) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#8 0x7fa51f12cec6 (/lib64/libxkbcommon.so.0+0x20ec6) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#9 0x7fa51f12e3c2 (/lib64/libxkbcommon.so.0+0x223c2) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#10 0x7fa51f12a4e5 in xkb_keymap_new_from_names (/lib64/libxkbcommon.so.0+0x1e4e5) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5) systemd#11 0x5574dd63f864 in verify_xkb_rmlvo /usr/src/debug/systemd/src/locale/xkbcommon-util.c:69:14 (snip) ``` (cherry picked from commit 1860990) (cherry picked from commit 5d7d60b8dd01282adbe89084b479a51aaff4cf47) (cherry picked from commit 0c27a6f4b40d0e888cd93aa6120e379c88b8e0c4) (cherry picked from commit 630ed0c) (cherry picked from commit 7b1259f) (cherry picked from commit 98a17ff)

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 - (cherry picked from commit 1326d2d) (cherry picked from commit de5f0a3)

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) ``` (cherry picked from commit 1860990) (cherry picked from commit 5d7d60b8dd01282adbe89084b479a51aaff4cf47) (cherry picked from commit 0c27a6f4b40d0e888cd93aa6120e379c88b8e0c4) (cherry picked from commit 630ed0c) (cherry picked from commit 7b1259f) (cherry picked from commit 98a17ff)

ghost mentioned this pull request Apr 23, 2018

Cannot run multiple unprivileged systemd-nspawn containers simultaneously systemd/systemd#8599

Closed

keszybz merged commit d26eb9c into systemd:v238-stable Oct 28, 2018

yuwata pushed a commit to yuwata/systemd-stable that referenced this pull request Mar 30, 2022

man: cross-link to BLS in more places, use "Type systemd#1", "Type sy…

a0aa383

…stemd#2" as appropriate

Cody-Learner mentioned this pull request Apr 29, 2024

Any chance to backport #32224 to V255? #391

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

nspawn: wait for network namespace creation before interface setup (#… #2

nspawn: wait for network namespace creation before interface setup (#… #2

Uh oh!

ghost commented Apr 21, 2018

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

Uh oh!

nspawn: wait for network namespace creation before interface setup (#… #2

nspawn: wait for network namespace creation before interface setup (#… #2

Uh oh!

Conversation

ghost commented Apr 21, 2018

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants