Candidate for v228.1 release #7
Merged
Conversation
This file contains 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
If the last reference to a user is released, we queue stop-jobs for the user-service and slice. Only once those are finished, we drop the user-object. However, if a new session is opened before the user object is fully dropped, we currently incorrectly re-use the object. This has the effect, that we get stale sessions without a valid "elogind --user" instance. Fix this by properly allowing user_start() to be called, even if user->stopping is true.
The child process is shortliving, hence always set O_NOCTTY so that the tty doesn't quickly become controlling TTY and then gives it up again. Also set O_CLOEXEC, because it's cleaner, and doesn't affect the parent anyway.
No change in behaviour, just make the code more obvious.
CMSG_NXTHDR() checks for cmsg->cmsg_len *after* it increased the pointer. While this makes sense for parsing received messages, that's a pitfall for code crafting messages with this macro. Wipe out the allocated memory to fix this.
When the Suspend method is called, the only log message we write (unless debugging is enabled) is "Operation finished.". This is not very helpful when trying to figure out what is going on, so add what operation we are talking about to the message: "Operation 'sleep' finished.". Hat tip to Daniel Aleksandersen for pointing this out.
It's only a header file, definining format strings for basic system types, hence it should be in src/basic/, not src/shared/.
We usually avoid relying on C's degrade-to-boolean functionality when comparing numerical variables with 0. We use it only for pointers and actual booleans.
The existing text misleads readers into thinking how the notify socket protocol is "internals" and that they can only use the functions. However, the socket is part of the Interface Stability Promise. So, we should drop "internally" from the description so the man page both indicates both how the functions work and how one would talk to the socket directly.
We already filter out 0, and as -1 is usually special (meaning infinity, as in USEC_INFINITY) we should better not accept it either. Better safe than sorry...
ARM/AArch64 guests now have SMBIOS tables populated (when boot with a late enough QEMU and a late enough AAVMF is used as the bootloader). Furthermore, when booting ARM/AArch64 guests with ACPI, the DT detection obviously no longer works, so we need dmi detection.
Some guests (ARM, AArch64, x86-RHEL) have 'KVM' in the product name. Look for that first in order to more precisely report "kvm" when detecting a QEMU/KVM guest. Without this patch we report "qemu", even if KVM acceleration is in use on ARM/AArch64 guests. I've only tested a backported version of this and the previous patch on an AArch64 guest (which worked). Of course it would be nice to get regression testing on all guest types that depend on dmi done.
afaict, this will fix a regression caused by commit 75f86906c5. Where we used to report "kvm" before that patch, without this patch, we would only report "qemu". The reason is because cpuid detection must come before dmi detection. Also, both can safely come before other xen heuristics. Untested.
…ZATION_CONTAINER_OTHER If we don't know a container manager, we should consider it as "other" rather than as no container manager at all, to provide a somwhat useful upgrade path.
After all, we don't actually really need the slice to work, it's just nice to have it.
Use unaligned_read_le64() to access input buffer when reading complete 64-bit words. This should fix memory traps on platforms with strict aliasing.
|
Sorry for the delay. Last friday my laptop broke down (hard drive failure). A new drive has been ordered, but it will take a few more days until it arrives. However, I'll be merging v228 later this day from an alternative machine. On both this alternative machine and my raspberry pi 3, elogind-228 works without an issue. |
Yamakuzure
pushed a commit
that referenced
this pull request
Aug 23, 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`
Yamakuzure
pushed a commit
that referenced
this pull request
Aug 24, 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`
Yamakuzure
pushed a commit
that referenced
this pull request
Apr 24, 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 6a461d1f59850ff27bd254a3b71fe9ade0523e76)
Yamakuzure
pushed a commit
that referenced
this pull request
Sep 23, 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 ()
Yamakuzure
pushed a commit
that referenced
this pull request
Sep 23, 2019
We would not send the property because we'd call sd_bus_get_current_message() which would return NULL. If there is no message, we cannot support /self or /auto, but things are still OK if a path with a session name is given. Traceback when the issue is triggered: #2 we'd call sd_bus_get_current_message() here, which would return NULL, and session_object_find() would immediately return 0. #3 0x00000000004289b7 in session_object_find (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x9efda0 "org.freedesktop.login1.Session", userdata=0x9852f0, found=0x7ffe3e975fe8, error=0x7ffe3e9760b0) at ../src/login/logind-session-dbus.c:620 #4 0x00007ff74bfdde39 in node_vtable_get_userdata (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", c=0x9f6d58, userdata=0x7ffe3e976070, error=0x7ffe3e9760b0) at ../src/libsystemd/sd-bus/bus-objects.c:37 #5 0x00007ff74bfe49af in emit_properties_changed_on_interface (bus=0x9f1110, prefix=0xa133a0 "/org/freedesktop/login1/session", path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x43f9f8 "org.freedesktop.login1.Session", require_fallback=true, found_interface=0x7ffe3e976163, names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2088 #6 0x00007ff74bfe56a4 in sd_bus_emit_properties_changed_strv (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x43f9f8 "org.freedesktop.login1.Session", names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2291 #7 0x00000000004292ea in session_send_changed (s=0xa16e10, properties=0x43ee27 "Active") at ../src/login/logind-session-dbus.c:730 #8 0x0000000000424cd7 in seat_set_active (s=0x9ee280, session=0xa16e10) at ../src/login/logind-seat.c:249 #9 0x00000000004251cf in seat_active_vt_changed (s=0x9ee280, vtnr=3) at ../src/login/logind-seat.c:361 #10 0x000000000042547b in seat_read_active_vt (s=0x9ee280) at ../src/login/logind-seat.c:395 #11 0x000000000040ab5c in manager_dispatch_console (s=0x9f0320, fd=8, revents=8, userdata=0x9852f0) at ../src/login/logind.c:588 #12 0x00007ff74c042d5f in source_dispatch (s=0x9f0320) at ../src/libsystemd/sd-event/sd-event.c:2828 #13 0x00007ff74c04469f in sd_event_dispatch (e=0x9ef340) at ../src/libsystemd/sd-event/sd-event.c:3241 #14 0x00007ff74c044b58 in sd_event_run (e=0x9ef340, timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3299 #15 0x000000000040d7e8 in manager_run (m=0x9852f0) at ../src/login/logind.c:1186 #16 0x000000000040db58 in run (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1234 #17 0x000000000040dc30 in main (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1244 Fixes #13437. Bug introduced in 3b92c086a8d5338e2164ffa0ae48b3d03d10cfb5.
Yamakuzure
pushed a commit
that referenced
this pull request
Feb 1, 2020
We would not send the property because we'd call sd_bus_get_current_message() which would return NULL. If there is no message, we cannot support /self or /auto, but things are still OK if a path with a session name is given. Traceback when the issue is triggered: #2 we'd call sd_bus_get_current_message() here, which would return NULL, and session_object_find() would immediately return 0. #3 0x00000000004289b7 in session_object_find (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x9efda0 "org.freedesktop.login1.Session", userdata=0x9852f0, found=0x7ffe3e975fe8, error=0x7ffe3e9760b0) at ../src/login/logind-session-dbus.c:620 #4 0x00007ff74bfdde39 in node_vtable_get_userdata (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", c=0x9f6d58, userdata=0x7ffe3e976070, error=0x7ffe3e9760b0) at ../src/libsystemd/sd-bus/bus-objects.c:37 #5 0x00007ff74bfe49af in emit_properties_changed_on_interface (bus=0x9f1110, prefix=0xa133a0 "/org/freedesktop/login1/session", path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x43f9f8 "org.freedesktop.login1.Session", require_fallback=true, found_interface=0x7ffe3e976163, names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2088 #6 0x00007ff74bfe56a4 in sd_bus_emit_properties_changed_strv (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x43f9f8 "org.freedesktop.login1.Session", names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2291 #7 0x00000000004292ea in session_send_changed (s=0xa16e10, properties=0x43ee27 "Active") at ../src/login/logind-session-dbus.c:730 #8 0x0000000000424cd7 in seat_set_active (s=0x9ee280, session=0xa16e10) at ../src/login/logind-seat.c:249 #9 0x00000000004251cf in seat_active_vt_changed (s=0x9ee280, vtnr=3) at ../src/login/logind-seat.c:361 #10 0x000000000042547b in seat_read_active_vt (s=0x9ee280) at ../src/login/logind-seat.c:395 #11 0x000000000040ab5c in manager_dispatch_console (s=0x9f0320, fd=8, revents=8, userdata=0x9852f0) at ../src/login/logind.c:588 #12 0x00007ff74c042d5f in source_dispatch (s=0x9f0320) at ../src/libsystemd/sd-event/sd-event.c:2828 #13 0x00007ff74c04469f in sd_event_dispatch (e=0x9ef340) at ../src/libsystemd/sd-event/sd-event.c:3241 #14 0x00007ff74c044b58 in sd_event_run (e=0x9ef340, timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3299 #15 0x000000000040d7e8 in manager_run (m=0x9852f0) at ../src/login/logind.c:1186 #16 0x000000000040db58 in run (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1234 #17 0x000000000040dc30 in main (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1244 Fixes #13437. Bug introduced in 3b92c086a8d5338e2164ffa0ae48b3d03d10cfb5.
Yamakuzure
pushed a commit
that referenced
this pull request
Aug 31, 2020
Having taken a look at https://github.com/systemd/systemd/runs/645252074?check_suite_focus=true where fuzz-journal-remote failed with ``` AddressSanitizer:DEADLYSIGNAL ================================================================= ==16==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f864f98948e bp 0x7ffde5c6b7c0 sp 0x7ffde5c6b560 T0) ==16==The signal is caused by a READ memory access. ==16==Hint: address points to the zero page. SCARINESS: 10 (null-deref) #0 0x7f864f98948e in output_short /work/build/../../src/systemd/src/shared/logs-show.c #1 0x7f864f984624 in show_journal_entry /work/build/../../src/systemd/src/shared/logs-show.c:1154:15 #2 0x7f864f984b63 in show_journal /work/build/../../src/systemd/src/shared/logs-show.c:1239:21 #3 0x4cabab in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journal-remote.c:67:21 #4 0x51fd16 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:556:15 #5 0x51c330 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:470:3 #6 0x523700 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:765:7 #7 0x5246cd in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:792:3 #8 0x4de3d1 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:824:6 #9 0x4cfb47 in main /src/libfuzzer/FuzzerMain.cpp:19:10 #10 0x7f864e69782f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #11 0x41f2a8 in _start (out/fuzz-journal-remote+0x41f2a8) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /work/build/../../src/systemd/src/shared/logs-show.c in output_short ==16==ABORTING MS: 0 ; base unit: 0000000000000000000000000000000000000000 0x44,0x3d,0xa,0x5f,0x5f,0x52,0x45,0x41,0x4c,0x54,0x49,0x4d,0x45,0x5f,0x54,0x49,0x4d,0x45,0x53,0x54,0x41,0x4d,0x50,0x3d,0x31,0xa,0xa, D=\x0a__REALTIME_TIMESTAMP=1\x0a\x0a artifact_prefix='./'; Test unit written to ./crash-d635b9dd31cceff3c912fd45e1a58d7e90f0ad73 Base64: RD0KX19SRUFMVElNRV9USU1FU1RBTVA9MQoK ``` I was wondering why it hadn't been caught by the compiler even though clang should have failed to compile it with ``` ../src/shared/logs-show.c:624:25: warning: null passed to a callee that requires a non-null argument [-Wnonnull] print_multiline(f, 4 + fieldlen + 1, 0, OUTPUT_FULL_WIDTH, 0, false, ^ ../src/shared/logs-show.c:161:24: note: callee declares array parameter as static here size_t highlight[static 2]) { ^ ~~~~~~~~~~ ../src/shared/logs-show.c:1239:21: warning: null passed to a callee that requires a non-null argument [-Wnonnull] r = show_journal_entry(f, j, mode, n_columns, flags, NULL, NULL, ellipsized); ^ ~~~~ ../src/shared/logs-show.c:1133:30: note: callee declares array parameter as static here const size_t highlight[static 2], ^ ~~~~~~~~~~ 2 warnings generated. ``` Given that judging by systemd/systemd#13039 it doesn't seem to be the first time issues like that have been missed I think it would be better to turn nonnull on and get around false positives on a case-by-case basis with DISABLE_WARNING_NONNULL .. REENABLE_WARNING Reopens systemd/systemd#6119
Yamakuzure
pushed a commit
that referenced
this pull request
Aug 31, 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)
Yamakuzure
pushed a commit
that referenced
this pull request
Aug 10, 2021
This lets the libc/xcrypt allocate as much storage area as it needs. Should fix #16965: testsuite-46.sh[74]: ==74==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f3e972e1080 at pc 0x7f3e9be8deed bp 0x7ffce4f28530 sp 0x7ffce4f27ce0 testsuite-46.sh[74]: WRITE of size 131232 at 0x7f3e972e1080 thread T0 testsuite-46.sh[74]: #0 0x7f3e9be8deec (/usr/lib/clang/10.0.1/lib/linux/libclang_rt.asan-x86_64.so+0x9feec) testsuite-46.sh[74]: #1 0x559cd05a6412 in user_record_make_hashed_password /systemd-meson-build/../build/src/home/user-record-util.c:818:21 testsuite-46.sh[74]: #2 0x559cd058fb03 in create_home /systemd-meson-build/../build/src/home/homectl.c:1112:29 testsuite-46.sh[74]: #3 0x7f3e9b5b3058 in dispatch_verb /systemd-meson-build/../build/src/shared/verbs.c:103:24 testsuite-46.sh[74]: #4 0x559cd058c101 in run /systemd-meson-build/../build/src/home/homectl.c:3325:16 testsuite-46.sh[74]: #5 0x559cd058c00a in main /systemd-meson-build/../build/src/home/homectl.c:3328:1 testsuite-46.sh[74]: #6 0x7f3e9a88b151 in __libc_start_main (/usr/lib/libc.so.6+0x28151) testsuite-46.sh[74]: #7 0x559cd0583e7d in _start (/usr/bin/homectl+0x24e7d) testsuite-46.sh[74]: Address 0x7f3e972e1080 is located in stack of thread T0 at offset 32896 in frame testsuite-46.sh[74]: #0 0x559cd05a60df in user_record_make_hashed_password /systemd-meson-build/../build/src/home/user-record-util.c:789 testsuite-46.sh[74]: This frame has 6 object(s): testsuite-46.sh[74]: [32, 40) 'priv' (line 790) testsuite-46.sh[74]: [64, 72) 'np' (line 791) testsuite-46.sh[74]: [96, 104) 'salt' (line 809) testsuite-46.sh[74]: [128, 32896) 'cd' (line 810) testsuite-46.sh[74]: [33152, 33168) '.compoundliteral' <== Memory access at offset 32896 partially underflows this variable testsuite-46.sh[74]: [33184, 33192) 'new_array' (line 832) <== Memory access at offset 32896 partially underflows this variable testsuite-46.sh[74]: HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork testsuite-46.sh[74]: (longjmp and C++ exceptions *are* supported) testsuite-46.sh[74]: SUMMARY: AddressSanitizer: stack-buffer-overflow (/usr/lib/clang/10.0.1/lib/linux/libclang_rt.asan-x86_64.so+0x9feec) It seems 'struct crypt_data' is 32896 bytes, but libclang_rt wants more, at least 33168?
Yamakuzure
pushed a commit
that referenced
this pull request
Dec 23, 2022
This is a workaround for an issue in the memory sanitizer.
If a function is called with too many arguments, then the sanitizer
triggers the following false-positive warning:
==349==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f8b247134a7 in json_buildv /work/build/../../src/systemd/src/shared/json.c:3213:17
#1 0x7f8b24714231 in json_build /work/build/../../src/systemd/src/shared/json.c:4117:13
#2 0x7f8b24487fa5 in show_boot_entries /work/build/../../src/systemd/src/shared/bootspec.c:1424:29
#3 0x4a6a1b in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-bootspec.c:119:16
#4 0x4c6693 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#5 0x4c5e7a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
#6 0x4c7ce4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:826:7
#7 0x4c7f19 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:857:3
#8 0x4b757f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
#9 0x4e0bd2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#10 0x7f8b23ead082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
#11 0x41f69d in _start (build-out/fuzz-bootspec+0x41f69d)
Follow-up for #24541.
Fixes #24551.
Yamakuzure
pushed a commit
that referenced
this pull request
Dec 23, 2022
We would print the whole thing in extenso. Users generally don't care,
and would likely prefer to just get the compact identifier of the package
that they can use in a bug report or package manager commands.
Before:
systemd-coredump[40645]: [🡕] Process 1975 (gnome-shell) of user 1000 dumped core.
Module /usr/bin/gnome-shell (deleted) with build-id aafdb7d69a7efca937e490080ad9348541fc57d8
Metadata for module /usr/bin/gnome-shell (deleted) owned by FDO found: {
"type" : "rpm",
"name" : "gnome-shell",
"version" : "43~rc-3.fc37",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
Module /usr/lib64/gnome-shell/libgvc.so (deleted) with build-id 56cbb9862e1ee84ca1549b94f2b4cda03537613e
Metadata for module /usr/lib64/gnome-shell/libgvc.so (deleted) owned by FDO found: {
"type" : "rpm",
"name" : "gnome-shell",
"version" : "43~rc-2.fc37",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
Module /usr/lib64/libLLVM-14.so (deleted) with build-id ffa7e43f48eb4c189304c0241b1862710de4c3a4
Metadata for module /usr/lib64/libLLVM-14.so (deleted) owned by FDO found: {
"type" : "rpm",
"name" : "gnome-shell",
"version" : "43~rc-2.fc37",
"architecture" : "x86_64",
"osCpe" : "cpe:/o:fedoraproject:fedora:37"
}
After:
systemd-coredump[235218]: [🡕] Process 235216 (bash) of user 1000 dumped core.
Module libtinfo.so.6 from rpm ncurses-6.3-3.20220501.fc37.x86_64, build-id=71a04d23fd572525eb6efc47026c379725e06d96
Module bash from rpm bash-5.1.16-3.fc37.x86_64, build-id=6c936aff95a2ccda04a3fb685a81a84a0a8d10da
Stack trace of thread 235216:
#0 0x00007fa409ec8d8b kill (libc.so.6 + 0x38d8b)
#1 0x0000560d35e366b1 kill_builtin (bash + 0xad6b1)
#2 0x0000560d35dd7227 execute_builtin.lto_priv.0 (bash + 0x4e227)
#3 0x0000560d35dd0459 execute_simple_command (bash + 0x47459)
#4 0x0000560d35dd1de0 execute_command_internal (bash + 0x48de0)
#5 0x0000560d35e307aa parse_and_execute (bash + 0xa77aa)
#6 0x0000560d35e91b08 run_one_command.isra.0 (bash + 0x108b08)
#7 0x0000560d35dba07c main (bash + 0x3107c)
#8 0x00007fa409eb3510 __libc_start_call_main (libc.so.6 + 0x23510)
#9 0x00007fa409eb35c9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x235c9)
#10 0x0000560d35dbad85 _start (bash + 0x31d85)
timkenhan
pushed a commit
to timkenhan/elogind
that referenced
this pull request
Oct 24, 2023
[ 49.275617] testsuite-46.sh[1862]: ================================================================= [ 49.275870] testsuite-46.sh[1862]: ==1862==ERROR: LeakSanitizer: detected memory leaks [ 49.276039] testsuite-46.sh[1862]: Direct leak of 103 byte(s) in 14 object(s) allocated from: [ 49.276515] testsuite-46.sh[1862]: #0 0x7f4dbc07243b in strdup (/lib64/libasan.so.8+0x7243b) [ 49.276707] testsuite-46.sh[1862]: elogind#1 0x7f4dbb3900d5 in free_and_strdup ../src/basic/string-util.c:952 [ 49.276931] testsuite-46.sh[1862]: elogind#2 0x7f4dbb15c67d in json_dispatch_user_group_name ../src/shared/json.c:4699 [ 49.277134] testsuite-46.sh[1862]: elogind#3 0x7f4dbb16da9b in json_dispatch ../src/shared/json.c:4395 [ 49.277352] testsuite-46.sh[1862]: elogind#4 0x7f4dbb25b28e in userdb_on_query_reply ../src/shared/userdb.c:305 [ 49.277603] testsuite-46.sh[1862]: elogind#5 0x7f4dbb2748b9 in varlink_dispatch_reply ../src/shared/varlink.c:760 [ 49.277766] testsuite-46.sh[1862]: elogind#6 0x7f4dbb2748b9 in varlink_process ../src/shared/varlink.c:951 [ 49.277975] testsuite-46.sh[1862]: elogind#7 0x7f4dbb27a001 in defer_callback ../src/shared/varlink.c:1897 [ 49.278197] testsuite-46.sh[1862]: elogind#8 0x7f4dbb5d57dd in source_dispatch ../src/libsystemd/sd-event/sd-event.c:4191 [ 49.278421] testsuite-46.sh[1862]: elogind#9 0x7f4dbb5d685d in sd_event_dispatch ../src/libsystemd/sd-event/sd-event.c:4780 [ 49.278675] testsuite-46.sh[1862]: elogind#10 0x7f4dbb5d70bf in sd_event_run ../src/libsystemd/sd-event/sd-event.c:4841 [ 49.278873] testsuite-46.sh[1862]: elogind#11 0x7f4dbb257e7c in userdb_process ../src/shared/userdb.c:591 [ 49.279048] testsuite-46.sh[1862]: elogind#12 0x7f4dbb25f78f in membershipdb_iterator_get ../src/shared/userdb.c:1411 [ 49.279280] testsuite-46.sh[1862]: elogind#13 0x7f4dbb23a98c in user_record_show ../src/shared/user-record-show.c:187 [ 49.279504] testsuite-46.sh[1862]: elogind#14 0x404ae3 in show_user ../src/userdb/userdbctl.c:93 [ 49.279710] testsuite-46.sh[1862]: elogind#15 0x40b4f5 in display_user ../src/userdb/userdbctl.c:418 [ 49.279961] testsuite-46.sh[1862]: elogind#16 0x7f4dbb2804d2 in dispatch_verb ../src/shared/verbs.c:110 [ 49.280233] testsuite-46.sh[1862]: elogind#17 0x40dcf3 in run ../src/userdb/userdbctl.c:1327 [ 49.280434] testsuite-46.sh[1862]: elogind#18 0x40dcf3 in main ../src/userdb/userdbctl.c:1330 [ 49.280657] testsuite-46.sh[1862]: elogind#19 0x7f4db9e4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) [ 49.280907] testsuite-46.sh[1862]: SUMMARY: AddressSanitizer: 103 byte(s) leaked in 14 allocation(s).
timkenhan
pushed a commit
to timkenhan/elogind
that referenced
this pull request
Oct 24, 2023
As it might hide a possible allocation error since it uses
the returns_nonnull attribute:
AddressSanitizer:DEADLYSIGNAL
=================================================================
==8==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000004 (pc 0x7f317897db8d bp 0x7ffd436fe9a0 sp 0x7ffd436fe970 T0)
==8==The signal is caused by a WRITE memory access.
==8==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
#0 0x7f317897db8d in source_new /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:1214:18
elogind#1 0x7f317897e68c in sd_event_add_time /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:1417:13
elogind#2 0x7f317897a0f6 in event_reset_time /work/build/../../src/systemd/src/libsystemd/sd-event/event-util.c:68:21
elogind#3 0x4e2c8e in client_initialize_time_events /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:1366:13
elogind#4 0x4eb0fd in client_initialize_events /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:1380:9
elogind#5 0x4eb0fd in client_start_delayed /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:1410:16
elogind#6 0x4e30aa in client_start /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:1415:16
elogind#7 0x4e30aa in sd_dhcp_client_start /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:2045:13
elogind#8 0x4e700e in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/libsystemd-network/fuzz-dhcp-client.c:73:15
elogind#9 0x5062f8 in NaloFuzzerTestOneInput (/build/fuzz-dhcp-client+0x5062f8)
elogind#10 0x525283 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
elogind#11 0x524a6a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
elogind#12 0x526139 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
elogind#13 0x526e05 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
elogind#14 0x51616f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
elogind#15 0x516a38 in LLVMFuzzerRunDriver /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:925:10
elogind#16 0x506555 in main (/build/fuzz-dhcp-client+0x506555)
elogind#17 0x7f3177ce3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
elogind#18 0x420c4d in _start (/build/fuzz-dhcp-client+0x420c4d)
Found by Nallocfuzz.
timkenhan
pushed a commit
to timkenhan/elogind
that referenced
this pull request
Oct 24, 2023
We can't dereference the variant object directly, as it might be
a magic object (which has an address on a faulting page); use
json_variant_is_sensitive() instead that handles this case.
For example, with an empty array:
==1547789==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000023 (pc 0x7fd616ca9a18 bp 0x7ffcba1dc7c0 sp 0x7ffcba1dc6d0 T0)
==1547789==The signal is caused by a READ memory access.
==1547789==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
#0 0x7fd616ca9a18 in json_variant_strv ../src/shared/json.c:2190
elogind#1 0x408332 in oci_args ../src/nspawn/nspawn-oci.c:173
elogind#2 0x7fd616cc09ce in json_dispatch ../src/shared/json.c:4400
elogind#3 0x40addf in oci_process ../src/nspawn/nspawn-oci.c:428
elogind#4 0x7fd616cc09ce in json_dispatch ../src/shared/json.c:4400
elogind#5 0x41fef5 in oci_load ../src/nspawn/nspawn-oci.c:2187
elogind#6 0x4061e4 in LLVMFuzzerTestOneInput ../src/nspawn/fuzz-nspawn-oci.c:23
elogind#7 0x40691c in main ../src/fuzz/fuzz-main.c:50
elogind#8 0x7fd61564a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
elogind#9 0x7fd61564a5c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x275c8)
elogind#10 0x405da4 in _start (/home/fsumsal/repos/@systemd/systemd/build-san/fuzz-nspawn-oci+0x405da4)
DEDUP_TOKEN: json_variant_strv--oci_args--json_dispatch
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ../src/shared/json.c:2190 in json_variant_strv
==1547789==ABORTING
Or with an empty string in an array:
../src/shared/json.c:2202:39: runtime error: member access within misaligned address 0x000000000007 for type 'struct JsonVariant', which requires 8 byte alignment
0x000000000007: note: pointer points here
<memory cannot be printed>
#0 0x7f35f4ca9bcf in json_variant_strv ../src/shared/json.c:2202
elogind#1 0x408332 in oci_args ../src/nspawn/nspawn-oci.c:173
elogind#2 0x7f35f4cc09ce in json_dispatch ../src/shared/json.c:4400
elogind#3 0x40addf in oci_process ../src/nspawn/nspawn-oci.c:428
elogind#4 0x7f35f4cc09ce in json_dispatch ../src/shared/json.c:4400
elogind#5 0x41fef5 in oci_load ../src/nspawn/nspawn-oci.c:2187
elogind#6 0x4061e4 in LLVMFuzzerTestOneInput ../src/nspawn/fuzz-nspawn-oci.c:23
elogind#7 0x40691c in main ../src/fuzz/fuzz-main.c:50
elogind#8 0x7f35f364a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
elogind#9 0x7f35f364a5c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x275c8)
elogind#10 0x405da4 in _start (/home/fsumsal/repos/@systemd/systemd/build-san/fuzz-nspawn-oci+0x405da4)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/shared/json.c:2202:39 in
Note: this happens only if json_variant_copy() in json_variant_set_source() fails.
Found by Nallocfuzz.
Yamakuzure
pushed a commit
that referenced
this pull request
Nov 11, 2023
[ 49.275617] testsuite-46.sh[1862]: ================================================================= [ 49.275870] testsuite-46.sh[1862]: ==1862==ERROR: LeakSanitizer: detected memory leaks [ 49.276039] testsuite-46.sh[1862]: Direct leak of 103 byte(s) in 14 object(s) allocated from: [ 49.276515] testsuite-46.sh[1862]: #0 0x7f4dbc07243b in strdup (/lib64/libasan.so.8+0x7243b) [ 49.276707] testsuite-46.sh[1862]: #1 0x7f4dbb3900d5 in free_and_strdup ../src/basic/string-util.c:952 [ 49.276931] testsuite-46.sh[1862]: #2 0x7f4dbb15c67d in json_dispatch_user_group_name ../src/shared/json.c:4699 [ 49.277134] testsuite-46.sh[1862]: #3 0x7f4dbb16da9b in json_dispatch ../src/shared/json.c:4395 [ 49.277352] testsuite-46.sh[1862]: #4 0x7f4dbb25b28e in userdb_on_query_reply ../src/shared/userdb.c:305 [ 49.277603] testsuite-46.sh[1862]: #5 0x7f4dbb2748b9 in varlink_dispatch_reply ../src/shared/varlink.c:760 [ 49.277766] testsuite-46.sh[1862]: #6 0x7f4dbb2748b9 in varlink_process ../src/shared/varlink.c:951 [ 49.277975] testsuite-46.sh[1862]: #7 0x7f4dbb27a001 in defer_callback ../src/shared/varlink.c:1897 [ 49.278197] testsuite-46.sh[1862]: #8 0x7f4dbb5d57dd in source_dispatch ../src/libsystemd/sd-event/sd-event.c:4191 [ 49.278421] testsuite-46.sh[1862]: #9 0x7f4dbb5d685d in sd_event_dispatch ../src/libsystemd/sd-event/sd-event.c:4780 [ 49.278675] testsuite-46.sh[1862]: #10 0x7f4dbb5d70bf in sd_event_run ../src/libsystemd/sd-event/sd-event.c:4841 [ 49.278873] testsuite-46.sh[1862]: #11 0x7f4dbb257e7c in userdb_process ../src/shared/userdb.c:591 [ 49.279048] testsuite-46.sh[1862]: #12 0x7f4dbb25f78f in membershipdb_iterator_get ../src/shared/userdb.c:1411 [ 49.279280] testsuite-46.sh[1862]: #13 0x7f4dbb23a98c in user_record_show ../src/shared/user-record-show.c:187 [ 49.279504] testsuite-46.sh[1862]: #14 0x404ae3 in show_user ../src/userdb/userdbctl.c:93 [ 49.279710] testsuite-46.sh[1862]: #15 0x40b4f5 in display_user ../src/userdb/userdbctl.c:418 [ 49.279961] testsuite-46.sh[1862]: #16 0x7f4dbb2804d2 in dispatch_verb ../src/shared/verbs.c:110 [ 49.280233] testsuite-46.sh[1862]: #17 0x40dcf3 in run ../src/userdb/userdbctl.c:1327 [ 49.280434] testsuite-46.sh[1862]: #18 0x40dcf3 in main ../src/userdb/userdbctl.c:1330 [ 49.280657] testsuite-46.sh[1862]: #19 0x7f4db9e4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) [ 49.280907] testsuite-46.sh[1862]: SUMMARY: AddressSanitizer: 103 byte(s) leaked in 14 allocation(s).
Yamakuzure
pushed a commit
that referenced
this pull request
Nov 11, 2023
As it might hide a possible allocation error since it uses
the returns_nonnull attribute:
AddressSanitizer:DEADLYSIGNAL
=================================================================
==8==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000004 (pc 0x7f317897db8d bp 0x7ffd436fe9a0 sp 0x7ffd436fe970 T0)
==8==The signal is caused by a WRITE memory access.
==8==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
#0 0x7f317897db8d in source_new /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:1214:18
#1 0x7f317897e68c in sd_event_add_time /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:1417:13
#2 0x7f317897a0f6 in event_reset_time /work/build/../../src/systemd/src/libsystemd/sd-event/event-util.c:68:21
#3 0x4e2c8e in client_initialize_time_events /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:1366:13
#4 0x4eb0fd in client_initialize_events /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:1380:9
#5 0x4eb0fd in client_start_delayed /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:1410:16
#6 0x4e30aa in client_start /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:1415:16
#7 0x4e30aa in sd_dhcp_client_start /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp-client.c:2045:13
#8 0x4e700e in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/libsystemd-network/fuzz-dhcp-client.c:73:15
#9 0x5062f8 in NaloFuzzerTestOneInput (/build/fuzz-dhcp-client+0x5062f8)
#10 0x525283 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#11 0x524a6a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
#12 0x526139 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
#13 0x526e05 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
#14 0x51616f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
#15 0x516a38 in LLVMFuzzerRunDriver /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:925:10
#16 0x506555 in main (/build/fuzz-dhcp-client+0x506555)
#17 0x7f3177ce3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
#18 0x420c4d in _start (/build/fuzz-dhcp-client+0x420c4d)
Found by Nallocfuzz.
Yamakuzure
pushed a commit
that referenced
this pull request
Nov 11, 2023
We can't dereference the variant object directly, as it might be
a magic object (which has an address on a faulting page); use
json_variant_is_sensitive() instead that handles this case.
For example, with an empty array:
==1547789==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000023 (pc 0x7fd616ca9a18 bp 0x7ffcba1dc7c0 sp 0x7ffcba1dc6d0 T0)
==1547789==The signal is caused by a READ memory access.
==1547789==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
#0 0x7fd616ca9a18 in json_variant_strv ../src/shared/json.c:2190
#1 0x408332 in oci_args ../src/nspawn/nspawn-oci.c:173
#2 0x7fd616cc09ce in json_dispatch ../src/shared/json.c:4400
#3 0x40addf in oci_process ../src/nspawn/nspawn-oci.c:428
#4 0x7fd616cc09ce in json_dispatch ../src/shared/json.c:4400
#5 0x41fef5 in oci_load ../src/nspawn/nspawn-oci.c:2187
#6 0x4061e4 in LLVMFuzzerTestOneInput ../src/nspawn/fuzz-nspawn-oci.c:23
#7 0x40691c in main ../src/fuzz/fuzz-main.c:50
#8 0x7fd61564a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
#9 0x7fd61564a5c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x275c8)
#10 0x405da4 in _start (/home/fsumsal/repos/@systemd/systemd/build-san/fuzz-nspawn-oci+0x405da4)
DEDUP_TOKEN: json_variant_strv--oci_args--json_dispatch
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ../src/shared/json.c:2190 in json_variant_strv
==1547789==ABORTING
Or with an empty string in an array:
../src/shared/json.c:2202:39: runtime error: member access within misaligned address 0x000000000007 for type 'struct JsonVariant', which requires 8 byte alignment
0x000000000007: note: pointer points here
<memory cannot be printed>
#0 0x7f35f4ca9bcf in json_variant_strv ../src/shared/json.c:2202
#1 0x408332 in oci_args ../src/nspawn/nspawn-oci.c:173
#2 0x7f35f4cc09ce in json_dispatch ../src/shared/json.c:4400
#3 0x40addf in oci_process ../src/nspawn/nspawn-oci.c:428
#4 0x7f35f4cc09ce in json_dispatch ../src/shared/json.c:4400
#5 0x41fef5 in oci_load ../src/nspawn/nspawn-oci.c:2187
#6 0x4061e4 in LLVMFuzzerTestOneInput ../src/nspawn/fuzz-nspawn-oci.c:23
#7 0x40691c in main ../src/fuzz/fuzz-main.c:50
#8 0x7f35f364a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
#9 0x7f35f364a5c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x275c8)
#10 0x405da4 in _start (/home/fsumsal/repos/@systemd/systemd/build-san/fuzz-nspawn-oci+0x405da4)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/shared/json.c:2202:39 in
Note: this happens only if json_variant_copy() in json_variant_set_source() fails.
Found by Nallocfuzz.
Yamakuzure
pushed a commit
that referenced
this pull request
Jan 29, 2024
fuzzers randomly fail with the following:
```
==172==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f41169cb39b in update_argv /work/build/../../src/systemd/src/basic/argv-util.c:96:13
#1 0x7f41169cb39b in rename_process /work/build/../../src/systemd/src/basic/argv-util.c:210:16
#2 0x7f4116b6824e in safe_fork_full /work/build/../../src/systemd/src/basic/process-util.c:1516:21
#3 0x7f4116bffa36 in safe_fork /work/build/../../src/systemd/src/basic/process-util.h:191:16
#4 0x7f4116bffa36 in parse_timestamp /work/build/../../src/systemd/src/basic/time-util.c:1047:13
#5 0x4a61e6 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-time-util.c:16:16
#6 0x4c4a13 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#7 0x4c41fa in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
#8 0x4c58c9 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
#9 0x4c6595 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
#10 0x4b58ff in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
#11 0x4def52 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#12 0x7f4115ea3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: e678fe54a5d2c2092f8e47eb0b33105e380f7340)
#13 0x41f5ad in _start (build-out/fuzz-time-util+0x41f5ad)
DEDUP_TOKEN: update_argv--rename_process--safe_fork_full
Uninitialized value was created by an allocation of 'fv' in the stack frame of function 'have_effective_cap'
#0 0x7f41169d3540 in have_effective_cap /work/build/../../src/systemd/src/basic/capability-util.c:21
```
Yamakuzure
pushed a commit
that referenced
this pull request
Feb 4, 2024
Avoid passing a NULL message to sd_bus_message_is_signal(), to not trip
over an assertion:
[ 132.869436] H testsuite-82.sh[614]: + systemctl --no-block --check-inhibitors=yes soft-reboot
[ 132.967386] H systemd[1]: Created slice system-systemd\x2dcoredump.slice.
[ 133.018292] H systemd[1]: Starting inhibit.service...
[ 133.122610] H systemd[1]: Started systemd-coredump@0-665-0.service.
[ 133.163643] H systemd[1]: Started inhibit.service.
[ 133.206836] H testsuite-82.sh[614]: + exec sleep infinity
[ 133.236762] H systemd-logind[611]: The system will reboot now!
[ 135.891607] H systemd-coredump[667]: [🡕] Process 663 (busctl) of user 0 dumped core.
Stack trace of thread 663:
#0 0x00007f2ec45e6acf raise (libc.so.6 + 0x4eacf)
#1 0x00007f2ec45b9ea5 abort (libc.so.6 + 0x21ea5)
#2 0x00007f2ec4b5c9a6 log_assert_failed (libsystemd-shared-255.so + 0x1ff9a6)
#3 0x00007f2ec4b5dca5 log_assert_failed_return (libsystemd-shared-255.so + 0x200ca5)
#4 0x00007f2ec4bb3df6 sd_bus_message_is_signal (libsystemd-shared-255.so + 0x256df6)
#5 0x000000000040e478 monitor (busctl + 0xe478)
#6 0x000000000040e82f verb_monitor (busctl + 0xe82f)
#7 0x00007f2ec4b202cb dispatch_verb (libsystemd-shared-255.so + 0x1c32cb)
#8 0x00000000004074fa busctl_main (busctl + 0x74fa)
#9 0x0000000000407525 run (busctl + 0x7525)
#10 0x000000000040ff67 main (busctl + 0xff67)
#11 0x00007f2ec45d2d85 __libc_start_main (libc.so.6 + 0x3ad85)
#12 0x00000000004044be _start (busctl + 0x44be)
ELF object binary architecture: AMD x86-64
[ 136.141152] H dbus-daemon[634]: [system] Monitoring connection :1.2 closed.
[ 136.152233] H systemd[1]: busctl.service: Main process exited, code=dumped, status=6/ABRT
[ 136.153996] H systemd[1]: busctl.service: Failed with result 'core-dump'.
The asertion in question:
Assertion 'm' failed at src/libsystemd/sd-bus/bus-message.c:1015, function sd_bus_message_is_signal(). Aborting.
We can get a NULL message here through sd_bus_process() ->
bus_process_internal() -> process_running(), so let's handle this case
appropriately.
(cherry picked from commit b4a21d51487e21052af49b755d1707d4616e2977)
Yamakuzure
pushed a commit
that referenced
this pull request
Feb 4, 2024
Avoid passing a NULL message to sd_bus_message_is_signal(), to not trip
over an assertion:
[ 132.869436] H testsuite-82.sh[614]: + systemctl --no-block --check-inhibitors=yes soft-reboot
[ 132.967386] H systemd[1]: Created slice system-systemd\x2dcoredump.slice.
[ 133.018292] H systemd[1]: Starting inhibit.service...
[ 133.122610] H systemd[1]: Started systemd-coredump@0-665-0.service.
[ 133.163643] H systemd[1]: Started inhibit.service.
[ 133.206836] H testsuite-82.sh[614]: + exec sleep infinity
[ 133.236762] H systemd-logind[611]: The system will reboot now!
[ 135.891607] H systemd-coredump[667]: [🡕] Process 663 (busctl) of user 0 dumped core.
Stack trace of thread 663:
#0 0x00007f2ec45e6acf raise (libc.so.6 + 0x4eacf)
#1 0x00007f2ec45b9ea5 abort (libc.so.6 + 0x21ea5)
#2 0x00007f2ec4b5c9a6 log_assert_failed (libsystemd-shared-255.so + 0x1ff9a6)
#3 0x00007f2ec4b5dca5 log_assert_failed_return (libsystemd-shared-255.so + 0x200ca5)
#4 0x00007f2ec4bb3df6 sd_bus_message_is_signal (libsystemd-shared-255.so + 0x256df6)
#5 0x000000000040e478 monitor (busctl + 0xe478)
#6 0x000000000040e82f verb_monitor (busctl + 0xe82f)
#7 0x00007f2ec4b202cb dispatch_verb (libsystemd-shared-255.so + 0x1c32cb)
#8 0x00000000004074fa busctl_main (busctl + 0x74fa)
#9 0x0000000000407525 run (busctl + 0x7525)
#10 0x000000000040ff67 main (busctl + 0xff67)
#11 0x00007f2ec45d2d85 __libc_start_main (libc.so.6 + 0x3ad85)
#12 0x00000000004044be _start (busctl + 0x44be)
ELF object binary architecture: AMD x86-64
[ 136.141152] H dbus-daemon[634]: [system] Monitoring connection :1.2 closed.
[ 136.152233] H systemd[1]: busctl.service: Main process exited, code=dumped, status=6/ABRT
[ 136.153996] H systemd[1]: busctl.service: Failed with result 'core-dump'.
The asertion in question:
Assertion 'm' failed at src/libsystemd/sd-bus/bus-message.c:1015, function sd_bus_message_is_signal(). Aborting.
We can get a NULL message here through sd_bus_process() ->
bus_process_internal() -> process_running(), so let's handle this case
appropriately.
(cherry picked from commit b4a21d51487e21052af49b755d1707d4616e2977)
Yamakuzure
pushed a commit
that referenced
this pull request
Feb 18, 2024
We can't dereference the variant object directly, as it might be
a magic object (which has an address on a faulting page); use
json_variant_is_sensitive() instead that handles this case.
For example, with an empty array:
==1547789==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000023 (pc 0x7fd616ca9a18 bp 0x7ffcba1dc7c0 sp 0x7ffcba1dc6d0 T0)
==1547789==The signal is caused by a READ memory access.
==1547789==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
#0 0x7fd616ca9a18 in json_variant_strv ../src/shared/json.c:2190
#1 0x408332 in oci_args ../src/nspawn/nspawn-oci.c:173
#2 0x7fd616cc09ce in json_dispatch ../src/shared/json.c:4400
#3 0x40addf in oci_process ../src/nspawn/nspawn-oci.c:428
#4 0x7fd616cc09ce in json_dispatch ../src/shared/json.c:4400
#5 0x41fef5 in oci_load ../src/nspawn/nspawn-oci.c:2187
#6 0x4061e4 in LLVMFuzzerTestOneInput ../src/nspawn/fuzz-nspawn-oci.c:23
#7 0x40691c in main ../src/fuzz/fuzz-main.c:50
#8 0x7fd61564a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
#9 0x7fd61564a5c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x275c8)
#10 0x405da4 in _start (/home/fsumsal/repos/@systemd/systemd/build-san/fuzz-nspawn-oci+0x405da4)
DEDUP_TOKEN: json_variant_strv--oci_args--json_dispatch
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ../src/shared/json.c:2190 in json_variant_strv
==1547789==ABORTING
Or with an empty string in an array:
../src/shared/json.c:2202:39: runtime error: member access within misaligned address 0x000000000007 for type 'struct JsonVariant', which requires 8 byte alignment
0x000000000007: note: pointer points here
<memory cannot be printed>
#0 0x7f35f4ca9bcf in json_variant_strv ../src/shared/json.c:2202
#1 0x408332 in oci_args ../src/nspawn/nspawn-oci.c:173
#2 0x7f35f4cc09ce in json_dispatch ../src/shared/json.c:4400
#3 0x40addf in oci_process ../src/nspawn/nspawn-oci.c:428
#4 0x7f35f4cc09ce in json_dispatch ../src/shared/json.c:4400
#5 0x41fef5 in oci_load ../src/nspawn/nspawn-oci.c:2187
#6 0x4061e4 in LLVMFuzzerTestOneInput ../src/nspawn/fuzz-nspawn-oci.c:23
#7 0x40691c in main ../src/fuzz/fuzz-main.c:50
#8 0x7f35f364a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
#9 0x7f35f364a5c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x275c8)
#10 0x405da4 in _start (/home/fsumsal/repos/@systemd/systemd/build-san/fuzz-nspawn-oci+0x405da4)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/shared/json.c:2202:39 in
Note: this happens only if json_variant_copy() in json_variant_set_source() fails.
Found by Nallocfuzz.
(cherry picked from commit 909eb4c01de03a32c915a2267166501dca5b78f6)
(cherry picked from commit 58c1816aa43b96b5ce0953bc8ff78c37c4226216)
Yamakuzure
pushed a commit
that referenced
this pull request
Feb 18, 2024
Spotted while fuzzing #27890.
=================================================================
==908098==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x7f4efe6d81f5 in __interceptor_realloc.part.0 (/lib64/libasan.so.8+0xd81f5) (BuildId: dc689b05ca2577037af24700212bb5cce1f91c8a)
#1 0x7f4efb8e3ace in greedy_realloc ../src/basic/alloc-util.c:70
#2 0x7f4efb93b713 in extract_first_word ../src/basic/extract-word.c:62
#3 0x7f4efb970d50 in set_put_strsplit ../src/basic/hashmap.c:1902
#4 0x7f4efd76c27e in exec_context_deserialize ../src/core/execute-serialize.c:3341
#5 0x7f4efd778dcb in exec_deserialize ../src/core/execute-serialize.c:4122
#6 0x4032c0 in LLVMFuzzerTestOneInput ../src/core/fuzz-execute-serialize.c:60
#7 0x403c58 in main ../src/fuzz/fuzz-main.c:50
#8 0x7f4efecccb49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
#9 0x7f4efecccc0a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
#10 0x402344 in _start (/home/mrc0mmand/repos/@systemd/systemd/build-san/fuzz-execute-serialize+0x402344) (BuildId: 195f382cf1e39b9ba48d6dcf5a90f786d72837a8)
SUMMARY: AddressSanitizer: 64 byte(s) leaked in 1 allocation(s).
Aborted (core dumped)
==911550==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 17 byte(s) in 1 object(s) allocated from:
#0 0x4df281 in strdup (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x4df281) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
#1 0x7fe4ae2b38fc in _set_put_strndup_full /home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/../src/basic/hashmap.c:1868:21
#2 0x7fe4b0bad897 in exec_context_deserialize /home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/../src/core/execute-serialize.c:3914:29
#3 0x7fe4b0b80592 in exec_deserialize /home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/../src/core/execute-serialize.c:4109:13
#4 0x531d0f in LLVMFuzzerTestOneInput /home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/../src/core/fuzz-execute-serialize.c:59:16
#5 0x440594 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x440594) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
#6 0x43f9b9 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x43f9b9) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
#7 0x440fd5 in fuzzer::Fuzzer::MutateAndTestOne() (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x440fd5) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
#8 0x441955 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, std::allocator<fuzzer::SizedFile>>&) (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x441955) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
#9 0x42e151 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x42e151) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
#10 0x45a916 in main (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x45a916) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
#11 0x7fe4ac449b49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
#12 0x7fe4ac449c0a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
#13 0x422b74 in _start (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x422b74) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
SUMMARY: AddressSanitizer: 17 byte(s) leaked in 1 allocation(s).
(cherry picked from commit 9b412709f21a4868e1bc0bb3252a4d26e862633b)
(cherry picked from commit 7bd680bc62c3d071ae6b4b4a834f79b4eceff0d8)
(cherry picked from commit b97ec522397d66d7df7c32f010f383e1e817c771)
Yamakuzure
pushed a commit
that referenced
this pull request
Feb 18, 2024
fuzzers randomly fail with the following:
```
==172==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7f41169cb39b in update_argv /work/build/../../src/systemd/src/basic/argv-util.c:96:13
#1 0x7f41169cb39b in rename_process /work/build/../../src/systemd/src/basic/argv-util.c:210:16
#2 0x7f4116b6824e in safe_fork_full /work/build/../../src/systemd/src/basic/process-util.c:1516:21
#3 0x7f4116bffa36 in safe_fork /work/build/../../src/systemd/src/basic/process-util.h:191:16
#4 0x7f4116bffa36 in parse_timestamp /work/build/../../src/systemd/src/basic/time-util.c:1047:13
#5 0x4a61e6 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-time-util.c:16:16
#6 0x4c4a13 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#7 0x4c41fa in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
#8 0x4c58c9 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
#9 0x4c6595 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
#10 0x4b58ff in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
#11 0x4def52 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#12 0x7f4115ea3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: e678fe54a5d2c2092f8e47eb0b33105e380f7340)
#13 0x41f5ad in _start (build-out/fuzz-time-util+0x41f5ad)
DEDUP_TOKEN: update_argv--rename_process--safe_fork_full
Uninitialized value was created by an allocation of 'fv' in the stack frame of function 'have_effective_cap'
#0 0x7f41169d3540 in have_effective_cap /work/build/../../src/systemd/src/basic/capability-util.c:21
```
(cherry picked from commit e521898d83e219bca842ad172b076609509fb8ca)
(cherry picked from commit 00c146f03ce05b5c6305bcd4870db92c8a73e21c)
(cherry picked from commit 25dcd38c74271705bc177bc375ff3094446a950d)
Yamakuzure
pushed a commit
that referenced
this pull request
Feb 18, 2024
Avoid passing a NULL message to sd_bus_message_is_signal(), to not trip
over an assertion:
[ 132.869436] H testsuite-82.sh[614]: + systemctl --no-block --check-inhibitors=yes soft-reboot
[ 132.967386] H systemd[1]: Created slice system-systemd\x2dcoredump.slice.
[ 133.018292] H systemd[1]: Starting inhibit.service...
[ 133.122610] H systemd[1]: Started systemd-coredump@0-665-0.service.
[ 133.163643] H systemd[1]: Started inhibit.service.
[ 133.206836] H testsuite-82.sh[614]: + exec sleep infinity
[ 133.236762] H systemd-logind[611]: The system will reboot now!
[ 135.891607] H systemd-coredump[667]: [🡕] Process 663 (busctl) of user 0 dumped core.
Stack trace of thread 663:
#0 0x00007f2ec45e6acf raise (libc.so.6 + 0x4eacf)
#1 0x00007f2ec45b9ea5 abort (libc.so.6 + 0x21ea5)
#2 0x00007f2ec4b5c9a6 log_assert_failed (libsystemd-shared-255.so + 0x1ff9a6)
#3 0x00007f2ec4b5dca5 log_assert_failed_return (libsystemd-shared-255.so + 0x200ca5)
#4 0x00007f2ec4bb3df6 sd_bus_message_is_signal (libsystemd-shared-255.so + 0x256df6)
#5 0x000000000040e478 monitor (busctl + 0xe478)
#6 0x000000000040e82f verb_monitor (busctl + 0xe82f)
#7 0x00007f2ec4b202cb dispatch_verb (libsystemd-shared-255.so + 0x1c32cb)
#8 0x00000000004074fa busctl_main (busctl + 0x74fa)
#9 0x0000000000407525 run (busctl + 0x7525)
#10 0x000000000040ff67 main (busctl + 0xff67)
#11 0x00007f2ec45d2d85 __libc_start_main (libc.so.6 + 0x3ad85)
#12 0x00000000004044be _start (busctl + 0x44be)
ELF object binary architecture: AMD x86-64
[ 136.141152] H dbus-daemon[634]: [system] Monitoring connection :1.2 closed.
[ 136.152233] H systemd[1]: busctl.service: Main process exited, code=dumped, status=6/ABRT
[ 136.153996] H systemd[1]: busctl.service: Failed with result 'core-dump'.
The asertion in question:
Assertion 'm' failed at src/libsystemd/sd-bus/bus-message.c:1015, function sd_bus_message_is_signal(). Aborting.
We can get a NULL message here through sd_bus_process() ->
bus_process_internal() -> process_running(), so let's handle this case
appropriately.
(cherry picked from commit b4a21d51487e21052af49b755d1707d4616e2977)
(cherry picked from commit ac851effbe936cbeb4b1d8f32016fa4458342a87)
(cherry picked from commit 5a5dcc251c59fa5678cdaef6679e771117127162)
(cherry picked from commit 7799a6e9e1a3ae8a6407c37d394474fcaaf8cf53)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This is the cleaned up dev_v228 branch.
The original branch got a bit messy after back- (and forth-) porting several changes between dev_v227 and dev_v228.
There aren't any major changes between v227 and v228, but a lot of files got moved around (again!) and I took the opportunity to do another major cleanup.