Repository navigation
nspawn: wait for network namespace creation before interface setup (#… - #2
Merged
Merged
Conversation
…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)
ghost
mentioned this pull request
eworm-de
pushed a commit
that referenced
this pull request
Jun 22, 2018
`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`
eworm-de
pushed a commit
that referenced
this pull request
Jun 22, 2018
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().
keszybz
pushed a commit
that referenced
this pull request
Feb 7, 2019
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)
eworm-de
pushed a commit
that referenced
this pull request
Feb 14, 2019
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.
eworm-de
pushed a commit
that referenced
this pull request
Feb 14, 2019
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.
keszybz
added a commit
that referenced
this pull request
Mar 29, 2019
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)
eworm-de
pushed a commit
that referenced
this pull request
Apr 11, 2019
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 ()
keszybz
pushed a commit
that referenced
this pull request
Feb 5, 2020
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)
keszybz
pushed a commit
that referenced
this pull request
May 31, 2020
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)
keszybz
added a commit
that referenced
this pull request
Jul 27, 2020
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)
keszybz
pushed a commit
that referenced
this pull request
Sep 20, 2020
```
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)
keszybz
pushed a commit
that referenced
this pull request
Sep 20, 2020
```
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)
keszybz
added a commit
that referenced
this pull request
Mar 12, 2021
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)
keszybz
added a commit
that referenced
this pull request
Mar 12, 2021
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)
keszybz
added a commit
that referenced
this pull request
Mar 23, 2021
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)
keszybz
added a commit
that referenced
this pull request
Mar 23, 2021
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)
keszybz
added a commit
that referenced
this pull request
Jan 10, 2022
It was reported as used by the linker: > [It is] called in the setup of ld-linux-x86-64.so.2 from _dl_sysdep_start. > My local call stack (with LTO): > > #0 init_cpu_features.constprop.0 (/usr/lib64/ld-linux-x86-64.so.2) > #1 _dl_sysdep_start (/usr/lib64/ld-linux-x86-64.so.2) > #2 _dl_start (/usr/lib64/ld-linux-x86-64.so.2) > #3 _start (/usr/lib64/ld-linux-x86-64.so.2) > > Looking through the source, I think it's this (links for glibc 2.34): > - First dl_platform_init calls _dl_x86_init_cpu_features, a wrapper for init_cpu_features. > - Then init_cpu_features calls get_cet_status. > - At last, get_cet_status invokes arch_prctl. Fixes #22033. (cherry picked from commit 5f02870)
keszybz
added a commit
that referenced
this pull request
Jan 11, 2022
It was reported as used by the linker: > [It is] called in the setup of ld-linux-x86-64.so.2 from _dl_sysdep_start. > My local call stack (with LTO): > > #0 init_cpu_features.constprop.0 (/usr/lib64/ld-linux-x86-64.so.2) > #1 _dl_sysdep_start (/usr/lib64/ld-linux-x86-64.so.2) > #2 _dl_start (/usr/lib64/ld-linux-x86-64.so.2) > #3 _start (/usr/lib64/ld-linux-x86-64.so.2) > > Looking through the source, I think it's this (links for glibc 2.34): > - First dl_platform_init calls _dl_x86_init_cpu_features, a wrapper for init_cpu_features. > - Then init_cpu_features calls get_cet_status. > - At last, get_cet_status invokes arch_prctl. Fixes #22033. (cherry picked from commit 5f02870) (cherry picked from commit d08f6ff)
keszybz
added a commit
that referenced
this pull request
Jan 13, 2022
It was reported as used by the linker: > [It is] called in the setup of ld-linux-x86-64.so.2 from _dl_sysdep_start. > My local call stack (with LTO): > > #0 init_cpu_features.constprop.0 (/usr/lib64/ld-linux-x86-64.so.2) > #1 _dl_sysdep_start (/usr/lib64/ld-linux-x86-64.so.2) > #2 _dl_start (/usr/lib64/ld-linux-x86-64.so.2) > #3 _start (/usr/lib64/ld-linux-x86-64.so.2) > > Looking through the source, I think it's this (links for glibc 2.34): > - First dl_platform_init calls _dl_x86_init_cpu_features, a wrapper for init_cpu_features. > - Then init_cpu_features calls get_cet_status. > - At last, get_cet_status invokes arch_prctl. Fixes #22033. (cherry picked from commit 5f02870) (cherry picked from commit d08f6ff) (cherry picked from commit cf6d1dc)
yuwata
pushed a commit
that referenced
this pull request
Jan 31, 2022
It was reported as used by the linker: > [It is] called in the setup of ld-linux-x86-64.so.2 from _dl_sysdep_start. > My local call stack (with LTO): > > #0 init_cpu_features.constprop.0 (/usr/lib64/ld-linux-x86-64.so.2) > #1 _dl_sysdep_start (/usr/lib64/ld-linux-x86-64.so.2) > #2 _dl_start (/usr/lib64/ld-linux-x86-64.so.2) > #3 _start (/usr/lib64/ld-linux-x86-64.so.2) > > Looking through the source, I think it's this (links for glibc 2.34): > - First dl_platform_init calls _dl_x86_init_cpu_features, a wrapper for init_cpu_features. > - Then init_cpu_features calls get_cet_status. > - At last, get_cet_status invokes arch_prctl. Fixes #22033.
yuwata
pushed a commit
that referenced
this pull request
Jan 31, 2022
by always calling journal_remote_server_destroy, which resets global
variables like journal_remote_server_global. It should prevent crashes like
```
Assertion 'journal_remote_server_global == NULL' failed at src/journal-remote/journal-remote.c:312, function int journal_remote_server_init(RemoteServer *, const char *, JournalWriteSplitMode, _Bool, _Bool)(). Aborting.
AddressSanitizer:DEADLYSIGNAL
=================================================================
==24769==ERROR: AddressSanitizer: ABRT on unknown address 0x0539000060c1 (pc 0x7f23b4d5818b bp 0x7ffcbc4080c0 sp 0x7ffcbc407e70 T0)
SCARINESS: 10 (signal)
#0 0x7f23b4d5818b in raise /build/glibc-eX1tMB/glibc-2.31/sysdeps/unix/sysv/linux/raise.c:51:1
#1 0x7f23b4d37858 in abort /build/glibc-eX1tMB/glibc-2.31/stdlib/abort.c:79:7
#2 0x7f23b5731809 in log_assert_failed systemd/src/basic/log.c:866:9
```
yuwata
pushed a commit
that referenced
this pull request
Jan 31, 2022
Turns out that part of systemd isn't covered by any fuzz targets and
that's not ideal considering that it parses data sent remotely. The
fuzzer triggers an infinite loop in lease_parse_routes as soon as it
starts so it seems to be working :-)
```
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 23620602
INFO: Loaded 2 modules (182073 inline 8-bit counters): 176548 [0x7fdf511fc8d0, 0x7fdf51227a74), 5525 [0x5f6ef0, 0x5f8485),
INFO: Loaded 2 PC tables (182073 PCs): 176548 [0x7fdf51227a78,0x7fdf514d94b8), 5525 [0x5f8488,0x60ddd8),
./build/fuzz-dhcp-client: Running 1 inputs 1 time(s) each.
Running: test/fuzz/fuzz-dhcp-client/timeout-ed34161922c7075c4773f2ada3dee8685d220980
ALARM: working on the last Unit for 31 seconds
and the timeout value is 30 (use -timeout=N to change)
==80731== ERROR: libFuzzer: timeout after 31 seconds
#0 0x51b32e in __sanitizer_print_stack_trace (/home/vagrant/systemd/build/fuzz-dhcp-client+0x51b32e)
#1 0x4689e9 in fuzzer::PrintStackTrace() (/home/vagrant/systemd/build/fuzz-dhcp-client+0x4689e9)
#2 0x44a0f4 in fuzzer::Fuzzer::StaticAlarmCallback() (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a0f4)
#3 0x7fdf4f8b474f (/lib64/libc.so.6+0x4274f)
#4 0x465fee in __sanitizer_cov_trace_const_cmp4 (/home/vagrant/systemd/build/fuzz-dhcp-client+0x465fee)
#5 0x57eee5 in lease_parse_routes /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:495:23
#6 0x57baf3 in dhcp_lease_parse_options /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:701:21
#7 0x572450 in parse_options /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:348:33
#8 0x571cea in dhcp_option_parse /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:381:21
#9 0x559a01 in client_handle_offer /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-client.c:1543:13
#10 0x5592bd in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/libsystemd-network/fuzz-dhcp-client.c:78:9
#11 0x44a379 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a379)
#12 0x42ae1f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x42ae1f)
#13 0x432ade in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x432ade)
#14 0x421f86 in main (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421f86)
#15 0x7fdf4f89f55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
#16 0x7fdf4f89f60b in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
#17 0x421fd4 in _start (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421fd4)
SUMMARY: libFuzzer: timeout
```
yuwata
pushed a commit
that referenced
this pull request
Jan 31, 2022
=================================================================
==81071==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x51245c in __interceptor_reallocarray (/home/vagrant/systemd/build/fuzz-dhcp-client+0x51245c)
#1 0x7f01440c67e6 in strv_push /home/vagrant/systemd/build/../src/basic/strv.c:435:13
#2 0x7f01440ca9e1 in strv_consume /home/vagrant/systemd/build/../src/basic/strv.c:506:13
#3 0x7f01440ca9e1 in strv_extend /home/vagrant/systemd/build/../src/basic/strv.c:558:16
#4 0x5806e3 in dhcp_lease_parse_search_domains /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:900:21
#5 0x57c1be in dhcp_lease_parse_options /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:727:21
#6 0x572450 in parse_options /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:348:33
#7 0x571c6a in dhcp_option_parse /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:376:13
#8 0x559a01 in client_handle_offer /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-client.c:1543:13
#9 0x5592bd in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/libsystemd-network/fuzz-dhcp-client.c:74:16
#10 0x44a379 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a379)
#11 0x42ae1f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x42ae1f)
#12 0x432ade in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x432ade)
#13 0x421f86 in main (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421f86)
#14 0x7f0142fff55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
bluca
pushed a commit
that referenced
this pull request
Feb 15, 2022
=================================================================
==81071==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x51245c in __interceptor_reallocarray (/home/vagrant/systemd/build/fuzz-dhcp-client+0x51245c)
#1 0x7f01440c67e6 in strv_push /home/vagrant/systemd/build/../src/basic/strv.c:435:13
#2 0x7f01440ca9e1 in strv_consume /home/vagrant/systemd/build/../src/basic/strv.c:506:13
#3 0x7f01440ca9e1 in strv_extend /home/vagrant/systemd/build/../src/basic/strv.c:558:16
#4 0x5806e3 in dhcp_lease_parse_search_domains /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:900:21
#5 0x57c1be in dhcp_lease_parse_options /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:727:21
#6 0x572450 in parse_options /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:348:33
#7 0x571c6a in dhcp_option_parse /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:376:13
#8 0x559a01 in client_handle_offer /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-client.c:1543:13
#9 0x5592bd in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/libsystemd-network/fuzz-dhcp-client.c:74:16
#10 0x44a379 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a379)
#11 0x42ae1f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x42ae1f)
#12 0x432ade in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x432ade)
#13 0x421f86 in main (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421f86)
#14 0x7f0142fff55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
(cherry picked from commit 9591c0a)
bluca
pushed a commit
that referenced
this pull request
Feb 15, 2022
=================================================================
==81071==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x51245c in __interceptor_reallocarray (/home/vagrant/systemd/build/fuzz-dhcp-client+0x51245c)
#1 0x7f01440c67e6 in strv_push /home/vagrant/systemd/build/../src/basic/strv.c:435:13
#2 0x7f01440ca9e1 in strv_consume /home/vagrant/systemd/build/../src/basic/strv.c:506:13
#3 0x7f01440ca9e1 in strv_extend /home/vagrant/systemd/build/../src/basic/strv.c:558:16
#4 0x5806e3 in dhcp_lease_parse_search_domains /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:900:21
#5 0x57c1be in dhcp_lease_parse_options /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:727:21
#6 0x572450 in parse_options /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:348:33
#7 0x571c6a in dhcp_option_parse /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:376:13
#8 0x559a01 in client_handle_offer /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-client.c:1543:13
#9 0x5592bd in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/libsystemd-network/fuzz-dhcp-client.c:74:16
#10 0x44a379 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a379)
#11 0x42ae1f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x42ae1f)
#12 0x432ade in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x432ade)
#13 0x421f86 in main (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421f86)
#14 0x7f0142fff55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
(cherry picked from commit 9591c0a)
(cherry picked from commit 7dc0f80)
yuwata
pushed a commit
to yuwata/systemd-stable
that referenced
this pull request
Mar 30, 2022
eworm-de
pushed a commit
that referenced
this pull request
May 5, 2022
```
timedatectl list-timezones --no-pager
...
==164329==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 8192 byte(s) in 1 object(s) allocated from:
#0 0x7fe8a74b6f8c in reallocarray (/lib64/libasan.so.6+0xaef8c)
#1 0x7fe8a63485dc in strv_push ../src/basic/strv.c:419
#2 0x7fe8a6349419 in strv_consume ../src/basic/strv.c:490
#3 0x7fe8a634958d in strv_extend ../src/basic/strv.c:542
#4 0x7fe8a643d787 in bus_message_read_strv_extend ../src/libsystemd/sd-bus/bus-message.c:5606
#5 0x7fe8a643db9d in sd_bus_message_read_strv ../src/libsystemd/sd-bus/bus-message.c:5628
#6 0x4085fb in list_timezones ../src/timedate/timedatectl.c:314
#7 0x7fe8a61ef3e1 in dispatch_verb ../src/shared/verbs.c:103
#8 0x410f91 in timedatectl_main ../src/timedate/timedatectl.c:1025
#9 0x41111c in run ../src/timedate/timedatectl.c:1043
#10 0x411242 in main ../src/timedate/timedatectl.c:1046
#11 0x7fe8a489df1f in __libc_start_call_main (/lib64/libc.so.6+0x40f1f)
```
keszybz
pushed a commit
that referenced
this pull request
May 25, 2022
```
timedatectl list-timezones --no-pager
...
==164329==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 8192 byte(s) in 1 object(s) allocated from:
#0 0x7fe8a74b6f8c in reallocarray (/lib64/libasan.so.6+0xaef8c)
#1 0x7fe8a63485dc in strv_push ../src/basic/strv.c:419
#2 0x7fe8a6349419 in strv_consume ../src/basic/strv.c:490
#3 0x7fe8a634958d in strv_extend ../src/basic/strv.c:542
#4 0x7fe8a643d787 in bus_message_read_strv_extend ../src/libsystemd/sd-bus/bus-message.c:5606
#5 0x7fe8a643db9d in sd_bus_message_read_strv ../src/libsystemd/sd-bus/bus-message.c:5628
#6 0x4085fb in list_timezones ../src/timedate/timedatectl.c:314
#7 0x7fe8a61ef3e1 in dispatch_verb ../src/shared/verbs.c:103
#8 0x410f91 in timedatectl_main ../src/timedate/timedatectl.c:1025
#9 0x41111c in run ../src/timedate/timedatectl.c:1043
#10 0x411242 in main ../src/timedate/timedatectl.c:1046
#11 0x7fe8a489df1f in __libc_start_call_main (/lib64/libc.so.6+0x40f1f)
```
(cherry picked from commit a2e37d5)
bluca
pushed a commit
to bluca/systemd-stable
that referenced
this pull request
Nov 4, 2022
=================================================================
==81071==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x51245c in __interceptor_reallocarray (/home/vagrant/systemd/build/fuzz-dhcp-client+0x51245c)
systemd#1 0x7f01440c67e6 in strv_push /home/vagrant/systemd/build/../src/basic/strv.c:435:13
systemd#2 0x7f01440ca9e1 in strv_consume /home/vagrant/systemd/build/../src/basic/strv.c:506:13
systemd#3 0x7f01440ca9e1 in strv_extend /home/vagrant/systemd/build/../src/basic/strv.c:558:16
systemd#4 0x5806e3 in dhcp_lease_parse_search_domains /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:900:21
systemd#5 0x57c1be in dhcp_lease_parse_options /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:727:21
systemd#6 0x572450 in parse_options /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:348:33
systemd#7 0x571c6a in dhcp_option_parse /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:376:13
systemd#8 0x559a01 in client_handle_offer /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-client.c:1543:13
systemd#9 0x5592bd in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/libsystemd-network/fuzz-dhcp-client.c:74:16
systemd#10 0x44a379 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a379)
systemd#11 0x42ae1f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x42ae1f)
systemd#12 0x432ade in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x432ade)
systemd#13 0x421f86 in main (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421f86)
systemd#14 0x7f0142fff55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
(cherry picked from commit 9591c0a)
(cherry picked from commit 7dc0f80)
(cherry picked from commit aaf7afb)
bluca
added a commit
that referenced
this pull request
Nov 5, 2022
…ocale= \#0 __strcmp_evex () at ../sysdeps/x86_64/multiarch/strcmp-evex.S:295 No locals. \#1 0x0000557444eb172b in process_locale () at ../src/firstboot/firstboot.c:342 etc_localeconf = 0x7ffd40217b80 "/root/root/etc/locale.conf" locales = {0x0, 0x0, 0x0} i = 0 r = <optimized out> __PRETTY_FUNCTION__ = "process_locale" __func__ = "process_locale" \#2 0x0000557444eaff93 in run (argv=0x7ffd40217d98, argc=3) at ../src/firstboot/firstboot.c:1401 loop_device = 0x0 unlink_dir = 0x0 r = <optimized out> loop_device = <optimized out> unlink_dir = <optimized out> r = <optimized out> __func__ = <optimized out> __PRETTY_FUNCTION__ = <optimized out> enabled = <optimized out> _error = <optimized out> _level = <optimized out> _e = <optimized out> _level = <optimized out> _e = <optimized out> \#3 main (argc=3, argv=0x7ffd40217d98) at ../src/firstboot/firstboot.c:1432 r = <optimized out> __PRETTY_FUNCTION__ = "main" Fixes systemd/systemd#25249 (cherry picked from commit 4c4a73c)
bluca
added a commit
to bluca/systemd-stable
that referenced
this pull request
Nov 5, 2022
…ocale= \#0 __strcmp_evex () at ../sysdeps/x86_64/multiarch/strcmp-evex.S:295 No locals. \systemd#1 0x0000557444eb172b in process_locale () at ../src/firstboot/firstboot.c:342 etc_localeconf = 0x7ffd40217b80 "/root/root/etc/locale.conf" locales = {0x0, 0x0, 0x0} i = 0 r = <optimized out> __PRETTY_FUNCTION__ = "process_locale" __func__ = "process_locale" \systemd#2 0x0000557444eaff93 in run (argv=0x7ffd40217d98, argc=3) at ../src/firstboot/firstboot.c:1401 loop_device = 0x0 unlink_dir = 0x0 r = <optimized out> loop_device = <optimized out> unlink_dir = <optimized out> r = <optimized out> __func__ = <optimized out> __PRETTY_FUNCTION__ = <optimized out> enabled = <optimized out> _error = <optimized out> _level = <optimized out> _e = <optimized out> _level = <optimized out> _e = <optimized out> \systemd#3 main (argc=3, argv=0x7ffd40217d98) at ../src/firstboot/firstboot.c:1432 r = <optimized out> __PRETTY_FUNCTION__ = "main" Fixes systemd/systemd#25249 (cherry picked from commit 4c4a73c) (cherry picked from commit a693cba)
bluca
added a commit
to bluca/systemd-stable
that referenced
this pull request
Nov 5, 2022
…ocale= \#0 __strcmp_evex () at ../sysdeps/x86_64/multiarch/strcmp-evex.S:295 No locals. \systemd#1 0x0000557444eb172b in process_locale () at ../src/firstboot/firstboot.c:342 etc_localeconf = 0x7ffd40217b80 "/root/root/etc/locale.conf" locales = {0x0, 0x0, 0x0} i = 0 r = <optimized out> __PRETTY_FUNCTION__ = "process_locale" __func__ = "process_locale" \systemd#2 0x0000557444eaff93 in run (argv=0x7ffd40217d98, argc=3) at ../src/firstboot/firstboot.c:1401 loop_device = 0x0 unlink_dir = 0x0 r = <optimized out> loop_device = <optimized out> unlink_dir = <optimized out> r = <optimized out> __func__ = <optimized out> __PRETTY_FUNCTION__ = <optimized out> enabled = <optimized out> _error = <optimized out> _level = <optimized out> _e = <optimized out> _level = <optimized out> _e = <optimized out> \systemd#3 main (argc=3, argv=0x7ffd40217d98) at ../src/firstboot/firstboot.c:1432 r = <optimized out> __PRETTY_FUNCTION__ = "main" Fixes systemd/systemd#25249 (cherry picked from commit 4c4a73c) (cherry picked from commit a693cba)
mrc0mmand
added a commit
to bluca/systemd-stable
that referenced
this pull request
Nov 7, 2022
This wrapper is used in situations where we don't care about *San reports,
we just want to make things work. However, with enabled LSan we might
trigger some bogus reports we're definitely not interested in, causing
unexpected test fails.
Spotted on C8S in TEST-34-DYNAMICUSERMIGRATE:
```
[10654.804162] testsuite-34.sh[56]: + systemctl start testservice-34-check-writable.service
Starting testservice-34-check-writable.service...
[10655.055969] bash[546]: + set -o pipefail
[10655.056127] bash[546]: + declare -a writable_dirs
[10655.056234] bash[546]: + readarray -t writable_dirs
[10655.060838] bash[548]: ++ find / '(' -path /var/tmp -o -path /tmp -o -path /proc -o -path /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf -o -path /dev/.lxc -o -path /sys/devices/system/cpu ')' -prune -o -type d -writable -print
[10655.061534] bash[549]: ++ sort -u
[10655.688740] bash[547]: =================================================================
[10655.689075] bash[547]: ==547==ERROR: LeakSanitizer: detected memory leaks
[10655.689246] bash[547]: Direct leak of 112 byte(s) in 1 object(s) allocated from:
[10655.743851] bash[547]: #0 0x7ffff752d364 (/usr/lib64/clang/14.0.0/lib/libclang_rt.asan-powerpc64le.so+0x13d364) (BuildId: 321f4ed1caea6a1a4c37f9272e07275cf16f034d)
[10655.744060] bash[547]: systemd#1 0x1000b5d20 in xmalloc (/usr/bin/bash+0xb5d20) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744224] bash[547]: systemd#2 0x100083338 (/usr/bin/bash+0x83338) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744393] bash[547]: systemd#3 0x10008847c (/usr/bin/bash+0x8847c) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744552] bash[547]: systemd#4 0x1000af6ec in redirection_expand (/usr/bin/bash+0xaf6ec) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744728] bash[547]: systemd#5 0x1000b005c (/usr/bin/bash+0xb005c) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744886] bash[547]: systemd#6 0x1000b1388 in do_redirections (/usr/bin/bash+0xb1388) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745051] bash[547]: systemd#7 0x100050484 (/usr/bin/bash+0x50484) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745208] bash[547]: systemd#8 0x100052160 in execute_command_internal (/usr/bin/bash+0x52160) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745376] bash[547]: systemd#9 0x100052a10 in execute_command_internal (/usr/bin/bash+0x52a10) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745536] bash[547]: systemd#10 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745711] bash[547]: systemd#11 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745870] bash[547]: systemd#12 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746038] bash[547]: systemd#13 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746198] bash[547]: systemd#14 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746367] bash[547]: systemd#15 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746548] bash[547]: systemd#16 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746741] bash[547]: systemd#17 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746897] bash[547]: systemd#18 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747067] bash[547]: systemd#19 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747227] bash[547]: systemd#20 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747414] bash[547]: systemd#21 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747573] bash[547]: systemd#22 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747741] bash[547]: systemd#23 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747896] bash[547]: systemd#24 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748064] bash[547]: systemd#25 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748225] bash[547]: systemd#26 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748390] bash[547]: systemd#27 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748553] bash[547]: systemd#28 0x1000bf91c in parse_and_execute (/usr/bin/bash+0xbf91c) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748717] bash[547]: systemd#29 0x1000311ec (/usr/bin/bash+0x311ec) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748883] bash[547]: Direct leak of 17 byte(s) in 1 object(s) allocated from:
...
```
(cherry picked from commit b8dd276)
bluca
added a commit
that referenced
this pull request
Nov 7, 2022
…ocale= \#0 __strcmp_evex () at ../sysdeps/x86_64/multiarch/strcmp-evex.S:295 No locals. \#1 0x0000557444eb172b in process_locale () at ../src/firstboot/firstboot.c:342 etc_localeconf = 0x7ffd40217b80 "/root/root/etc/locale.conf" locales = {0x0, 0x0, 0x0} i = 0 r = <optimized out> __PRETTY_FUNCTION__ = "process_locale" __func__ = "process_locale" \#2 0x0000557444eaff93 in run (argv=0x7ffd40217d98, argc=3) at ../src/firstboot/firstboot.c:1401 loop_device = 0x0 unlink_dir = 0x0 r = <optimized out> loop_device = <optimized out> unlink_dir = <optimized out> r = <optimized out> __func__ = <optimized out> __PRETTY_FUNCTION__ = <optimized out> enabled = <optimized out> _error = <optimized out> _level = <optimized out> _e = <optimized out> _level = <optimized out> _e = <optimized out> \#3 main (argc=3, argv=0x7ffd40217d98) at ../src/firstboot/firstboot.c:1432 r = <optimized out> __PRETTY_FUNCTION__ = "main" Fixes systemd/systemd#25249 (cherry picked from commit 4c4a73c) (cherry picked from commit a693cba)
bluca
pushed a commit
that referenced
this pull request
Nov 7, 2022
This wrapper is used in situations where we don't care about *San reports,
we just want to make things work. However, with enabled LSan we might
trigger some bogus reports we're definitely not interested in, causing
unexpected test fails.
Spotted on C8S in TEST-34-DYNAMICUSERMIGRATE:
```
[10654.804162] testsuite-34.sh[56]: + systemctl start testservice-34-check-writable.service
Starting testservice-34-check-writable.service...
[10655.055969] bash[546]: + set -o pipefail
[10655.056127] bash[546]: + declare -a writable_dirs
[10655.056234] bash[546]: + readarray -t writable_dirs
[10655.060838] bash[548]: ++ find / '(' -path /var/tmp -o -path /tmp -o -path /proc -o -path /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf -o -path /dev/.lxc -o -path /sys/devices/system/cpu ')' -prune -o -type d -writable -print
[10655.061534] bash[549]: ++ sort -u
[10655.688740] bash[547]: =================================================================
[10655.689075] bash[547]: ==547==ERROR: LeakSanitizer: detected memory leaks
[10655.689246] bash[547]: Direct leak of 112 byte(s) in 1 object(s) allocated from:
[10655.743851] bash[547]: #0 0x7ffff752d364 (/usr/lib64/clang/14.0.0/lib/libclang_rt.asan-powerpc64le.so+0x13d364) (BuildId: 321f4ed1caea6a1a4c37f9272e07275cf16f034d)
[10655.744060] bash[547]: #1 0x1000b5d20 in xmalloc (/usr/bin/bash+0xb5d20) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744224] bash[547]: #2 0x100083338 (/usr/bin/bash+0x83338) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744393] bash[547]: #3 0x10008847c (/usr/bin/bash+0x8847c) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744552] bash[547]: #4 0x1000af6ec in redirection_expand (/usr/bin/bash+0xaf6ec) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744728] bash[547]: #5 0x1000b005c (/usr/bin/bash+0xb005c) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.744886] bash[547]: #6 0x1000b1388 in do_redirections (/usr/bin/bash+0xb1388) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745051] bash[547]: #7 0x100050484 (/usr/bin/bash+0x50484) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745208] bash[547]: #8 0x100052160 in execute_command_internal (/usr/bin/bash+0x52160) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745376] bash[547]: #9 0x100052a10 in execute_command_internal (/usr/bin/bash+0x52a10) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745536] bash[547]: #10 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745711] bash[547]: #11 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.745870] bash[547]: #12 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746038] bash[547]: #13 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746198] bash[547]: #14 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746367] bash[547]: #15 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746548] bash[547]: #16 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746741] bash[547]: #17 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.746897] bash[547]: #18 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747067] bash[547]: #19 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747227] bash[547]: #20 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747414] bash[547]: #21 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747573] bash[547]: #22 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747741] bash[547]: #23 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.747896] bash[547]: #24 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748064] bash[547]: #25 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748225] bash[547]: #26 0x100053e38 in execute_command (/usr/bin/bash+0x53e38) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748390] bash[547]: #27 0x1000529d8 in execute_command_internal (/usr/bin/bash+0x529d8) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748553] bash[547]: #28 0x1000bf91c in parse_and_execute (/usr/bin/bash+0xbf91c) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748717] bash[547]: #29 0x1000311ec (/usr/bin/bash+0x311ec) (BuildId: da38eb38f6870bdc2a6ef51c52aa6ce20921fe40)
[10655.748883] bash[547]: Direct leak of 17 byte(s) in 1 object(s) allocated from:
...
```
(cherry picked from commit b8dd276)
bluca
pushed a commit
to bluca/systemd-stable
that referenced
this pull request
Jan 25, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
systemd#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
systemd#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
systemd#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
systemd#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
systemd#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
systemd#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
systemd#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
systemd#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
systemd#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab)
bluca
pushed a commit
to bluca/systemd-stable
that referenced
this pull request
Jan 25, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
systemd#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
systemd#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
systemd#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
systemd#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
systemd#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
systemd#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
systemd#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
systemd#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
systemd#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab)
bluca
pushed a commit
to bluca/systemd-stable
that referenced
this pull request
Jan 25, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
systemd#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
systemd#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
systemd#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
systemd#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
systemd#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
systemd#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
systemd#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
systemd#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
systemd#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab)
bluca
pushed a commit
to bluca/systemd-stable
that referenced
this pull request
Jan 25, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
systemd#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
systemd#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
systemd#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
systemd#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
systemd#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
systemd#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
systemd#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
systemd#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
systemd#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab)
bluca
pushed a commit
to bluca/systemd-stable
that referenced
this pull request
Jan 25, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
systemd#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
systemd#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
systemd#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
systemd#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
systemd#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
systemd#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
systemd#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
systemd#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
systemd#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab)
bluca
pushed a commit
to bluca/systemd-stable
that referenced
this pull request
Jan 25, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
systemd#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
systemd#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
systemd#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
systemd#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
systemd#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
systemd#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
systemd#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
systemd#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
systemd#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab)
keszybz
pushed a commit
that referenced
this pull request
Jan 26, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab)
bluca
pushed a commit
to bluca/systemd-stable
that referenced
this pull request
Jan 26, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
systemd#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
systemd#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
systemd#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
systemd#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
systemd#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
systemd#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
systemd#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
systemd#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
systemd#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab)
(cherry picked from commit a11a949)
bluca
pushed a commit
to bluca/systemd-stable
that referenced
this pull request
Jan 26, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
systemd#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
systemd#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
systemd#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
systemd#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
systemd#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
systemd#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
systemd#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
systemd#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
systemd#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab)
(cherry picked from commit a11a949)
bluca
pushed a commit
to bluca/systemd-stable
that referenced
this pull request
Jan 26, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
systemd#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
systemd#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
systemd#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
systemd#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
systemd#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
systemd#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
systemd#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
systemd#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
systemd#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab)
(cherry picked from commit a11a949)
bluca
pushed a commit
that referenced
this pull request
Jan 27, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab)
(cherry picked from commit a11a949)
bluca
pushed a commit
to bluca/systemd-stable
that referenced
this pull request
Jan 27, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
systemd#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
systemd#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
systemd#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
systemd#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
systemd#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
systemd#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
systemd#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
systemd#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
systemd#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab)
(cherry picked from commit a11a949)
(cherry picked from commit 4551936)
bluca
pushed a commit
that referenced
this pull request
Jan 28, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab)
(cherry picked from commit a11a949)
(cherry picked from commit 4551936)
bluca
pushed a commit
to bluca/systemd-stable
that referenced
this pull request
Jan 28, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.
Then we pass a null pointer into acl_free().
From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
#0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
systemd#1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
systemd#2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
systemd#3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
systemd#4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
systemd#5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
systemd#6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
systemd#7 0x7f65d7ebe289 (/usr/lib64/libc.so.6+0x23289)
systemd#8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
systemd#9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
(cherry picked from commit 9f804ab)
(cherry picked from commit a11a949)
(cherry picked from commit 4551936)
(cherry picked from commit 0e711b7)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…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)