Skip to content

Fix 7070#1

Closed
injust wants to merge 2 commits into
yuwata:masterfrom
injust:fix-7070
Closed

Fix 7070#1
injust wants to merge 2 commits into
yuwata:masterfrom
injust:fix-7070

Conversation

@injust
Copy link
Copy Markdown

@injust injust commented Oct 13, 2017

No description provided.

From 6c47cd7, RuntimeDirectory= and
their friends also imply BindPaths=. Thus, implying ReadWritePaths=
is meaningless.
…r freinds are set

When at least one of BindPaths=, BindReadOnlyPaths=, RootImage=,
RuntimeDirectory= or their friends are set, systemd prepares
RootDirectory= like namespace. Thus, ReadWritePaths= or their friends
without '+' prefix is completely meaningless.
So, let's assume '+' prefix when one of them are set.

Fixes systemd#7070 and systemd#7080.
@injust
Copy link
Copy Markdown
Author

injust commented Oct 13, 2017

Oops, didn't mean to do this

@injust injust closed this Oct 13, 2017
yuwata pushed a commit that referenced this pull request Dec 21, 2017
In general we'd leak anything that was allocated in the first parsing of
netdev, e.g. netdev name, host name, etc. Use normal netdev_unref to make sure
everything is freed.

--- command ---
/home/zbyszek/src/systemd/build2/test-network
--- stderr ---
/etc/systemd/network/wg0.netdev:3: Failed to parse netdev kind, ignoring: wireguard
/etc/systemd/network/wg0.netdev:5: Unknown section 'WireGuard'. Ignoring.
/etc/systemd/network/wg0.netdev:9: Unknown section 'WireGuardPeer'. Ignoring.
NetDev has no Kind configured in /etc/systemd/network/wg0.netdev. Ignoring
/etc/systemd/network/br0.network:13: Unknown lvalue 'NetDev' in section 'Network'
br0: netdev ready

=================================================================
==11666==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x7f3a314cf238 in __interceptor_strdup (/lib64/libasan.so.4+0x77238)
    #1 0x7f3a30e71ad1 in free_and_strdup ../src/basic/string-util.c:870
    #2 0x7f3a30d34fba in config_parse_ifname ../src/shared/conf-parser.c:981
    #3 0x7f3a30d2f5b0 in next_assignment ../src/shared/conf-parser.c:155
    #4 0x7f3a30d30303 in parse_line ../src/shared/conf-parser.c:273
    #5 0x7f3a30d30dee in config_parse ../src/shared/conf-parser.c:390
    #6 0x7f3a30d310a5 in config_parse_many_files ../src/shared/conf-parser.c:428
    #7 0x7f3a30d3181c in config_parse_many ../src/shared/conf-parser.c:487
    #8 0x55b4200f9b00 in netdev_load_one ../src/network/netdev/netdev.c:634
    #9 0x55b4200fb562 in netdev_load ../src/network/netdev/netdev.c:778
    #10 0x55b4200c607a in manager_load_config ../src/network/networkd-manager.c:1299
    #11 0x55b4200818e0 in test_load_config ../src/network/test-network.c:128
    #12 0x55b42008343b in main ../src/network/test-network.c:254
    #13 0x7f3a305f8889 in __libc_start_main (/lib64/libc.so.6+0x20889)

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
-------
yuwata pushed a commit that referenced this pull request Mar 10, 2018
Some versions of asan report the following false positive
when strict_string_checks=1 is passed:

=================================================================
==3297==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f64e4090286 bp 0x7ffe46acd9a0 sp 0x7ffe46acd118 T0)
==3297==The signal is caused by a READ memory access.
==3297==Hint: address points to the zero page.
    #0 0x7f64e4090285 in __strlen_sse2 (/lib64/libc.so.6+0xaa285)
    #1 0x7f64e5a51e46  (/lib64/libasan.so.4+0x41e46)
    #2 0x7f64e4e5e3a0  (/lib64/libglib-2.0.so.0+0x383a0)
    #3 0x7f64e4e5e536 in g_dgettext (/lib64/libglib-2.0.so.0+0x38536)
    #4 0x7f64e48fac5f  (/lib64/libgio-2.0.so.0+0xc1c5f)
    #5 0x7f64e4c03978 in g_type_class_ref (/lib64/libgobject-2.0.so.0+0x30978)
    #6 0x7f64e4be9567 in g_object_new_with_properties (/lib64/libgobject-2.0.so.0+0x16567)
    #7 0x7f64e4be9fd0 in g_object_new (/lib64/libgobject-2.0.so.0+0x16fd0)
    #8 0x7f64e48fd43e in g_dbus_message_new_from_blob (/lib64/libgio-2.0.so.0+0xc443e)
    #9 0x564a6aa0de52 in main ../src/libsystemd/sd-bus/test-bus-marshal.c:228
    #10 0x7f64e4007009 in __libc_start_main (/lib64/libc.so.6+0x21009)
    #11 0x564a6aa0a569 in _start (/home/vagrant/systemd/build/test-bus-marshal+0x5569)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0xaa285) in __strlen_sse2
==3297==ABORTING

It's an external library and errors in external libraries are generally not very
useful for looking for internal bugs.

It would be better not to change the code and use standard suppression
techinques decribed at
https://clang.llvm.org/docs/AddressSanitizer.html#suppressing-reports-in-external-libraries,
but, unfortunaley, none of them seems to be able to suppress fatal errors in asan intself.
yuwata pushed a commit that referenced this pull request Mar 13, 2018
Fuzzing with AddressSanitizer reports an error here:
==11==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7fe53f5497d8 at pc 0x7fe53ef055c9 bp 0x7ffd344e9380 sp 0x7ffd344e9378
READ of size 4 at 0x7fe53f5497d8 thread T0
SCARINESS: 27 (4-byte-read-global-buffer-overflow-far-from-bounds)
    #0 0x7fe53ef055c8 in bus_error_name_to_errno /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:118:24
    #1 0x7fe53ef0577b in bus_error_setfv /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:274:17
    #2 0x7fe53ef0595a in sd_bus_error_setf /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:284:21
    #3 0x561059 in manager_load_unit_prepare /work/build/../../src/systemd/src/core/manager.c
    #4 0x560680 in manager_load_unit /work/build/../../src/systemd/src/core/manager.c:1773:13
    #5 0x5d49a6 in unit_add_dependency_by_name /work/build/../../src/systemd/src/core/unit.c:2882:13
    #6 0x538996 in config_parse_unit_deps /work/build/../../src/systemd/src/core/load-fragment.c:152:21
    #7 0x6db771 in next_assignment /work/build/../../src/systemd/src/shared/conf-parser.c:155:32
    #8 0x6d697e in parse_line /work/build/../../src/systemd/src/shared/conf-parser.c:273:16
    #9 0x6d5c48 in config_parse /work/build/../../src/systemd/src/shared/conf-parser.c:390:21
    #10 0x535678 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-unit-file.c:41:16
    #11 0x73bd60 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:517:13
    #12 0x73a39f in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:442:3
    #13 0x73d9bc in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:650:19
    #14 0x73fa05 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:773:5
    #15 0x71f75d in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:754:6
    #16 0x71285c in main /src/libfuzzer/FuzzerMain.cpp:20:10
    #17 0x7fe53da0482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #18 0x430e68 in _start (/out/fuzz-unit-file+0x430e68)

0x7fe53f5497d8 is located 8 bytes to the right of global variable 'bus_common_errors' defined in '../../src/systemd/src/libsystemd/sd-bus/bus-common-errors.c:28:51' (0x7fe53f549300) of size 1232
SUMMARY: AddressSanitizer: global-buffer-overflow /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:118:24 in bus_error_name_to_errno
Shadow bytes around the buggy address:
  0x0ffd27ea12a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffd27ea12b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffd27ea12c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffd27ea12d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffd27ea12e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ffd27ea12f0: 00 00 00 00 00 00 00 00 00 00 f9[f9]f9 f9 f9 f9
  0x0ffd27ea1300: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0ffd27ea1310: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
  0x0ffd27ea1320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffd27ea1330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ffd27ea1340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==11==ABORTING

but I think it's a false positive because of our low-level magic in how this
area is constructed.
yuwata pushed a commit that referenced this pull request May 31, 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`
yuwata pushed a commit that referenced this pull request Jun 8, 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().
yuwata added a commit that referenced this pull request Jul 29, 2018
When a nested struct is initialized by structured initializer, then
padding space is not cleared by zero. So, before setting values,
this makes explicitly set zero including padding.

This fixes the following false positive warning by valgrind:
```
==492== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s)
==492==    at 0x56D0CF7: sendmsg (in /usr/lib64/libpthread-2.27.so)
==492==    by 0x4FDD3C5: sd_resolve_getaddrinfo (sd-resolve.c:975)
==492==    by 0x110B9E: manager_connect (timesyncd-manager.c:879)
==492==    by 0x10B729: main (timesyncd.c:165)
==492==  Address 0x1fff0008f1 is on thread 1's stack
==492==  in frame #1, created by sd_resolve_getaddrinfo (sd-resolve.c:928)
==492==
```
yuwata pushed a commit that referenced this pull request Aug 20, 2018
…g it

This fixes a memory leak:
```
d5070e2f67ededca022f81f2941900606b16f3196b2268e856295f59._openpgpkey.gmail.com: resolve call failed: 'd5070e2f67ededca022f81f2941900606b16f3196b2268e856295f59._openpgpkey.gmail.com' not found

=================================================================
==224==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 65 byte(s) in 1 object(s) allocated from:
    #0 0x7f71b0878850 in malloc (/usr/lib64/libasan.so.4+0xde850)
    #1 0x7f71afaf69b0 in malloc_multiply ../src/basic/alloc-util.h:63
    #2 0x7f71afaf6c95 in hexmem ../src/basic/hexdecoct.c:62
    #3 0x7f71afbb574b in string_hashsum ../src/basic/gcrypt-util.c:45
    #4 0x56201333e0b9 in string_hashsum_sha256 ../src/basic/gcrypt-util.h:30
    #5 0x562013347b63 in resolve_openpgp ../src/resolve/resolvectl.c:908
    #6 0x562013348b9f in verb_openpgp ../src/resolve/resolvectl.c:944
    #7 0x7f71afbae0b0 in dispatch_verb ../src/basic/verbs.c:119
    #8 0x56201335790b in native_main ../src/resolve/resolvectl.c:2947
    #9 0x56201335880d in main ../src/resolve/resolvectl.c:3087
    #10 0x7f71ad8fcf29 in __libc_start_main (/lib64/libc.so.6+0x20f29)

SUMMARY: AddressSanitizer: 65 byte(s) leaked in 1 allocation(s).
```
yuwata pushed a commit that referenced this pull request Sep 29, 2018
==14==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200055fa9c at pc 0x0000005458f1 bp 0x7ffc78940d90 sp 0x7ffc78940d88
READ of size 1 at 0x60200055fa9c thread T0
    #0 0x5458f0 in dhcp6_option_parse_domainname /work/build/../../src/systemd/src/libsystemd-network/dhcp6-option.c:555:29
    #1 0x54706e in dhcp6_lease_set_domains /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-lease.c:242:13
    #2 0x53fce0 in client_parse_message /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:984:29
    #3 0x53f3bc in client_receive_advertise /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:1083:13
    #4 0x53d57f in client_receive_message /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:1182:21
    #5 0x7f0f7159deee in source_dispatch /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3042:21
    #6 0x7f0f7159d431 in sd_event_dispatch /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3455:21
    #7 0x7f0f7159ea8d in sd_event_run /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3512:21
    #8 0x531f2b in fuzz_client /work/build/../../src/systemd/src/fuzz/fuzz-dhcp6-client.c:44:9
    #9 0x531bc1 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-dhcp6-client.c:53:9
    #10 0x57bec8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:570:15
    #11 0x579d67 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:479:3
    #12 0x57dc92 in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:707:19
    #13 0x580ca6 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:838:5
    #14 0x55e968 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:764:6
    #15 0x551a1c in main /src/libfuzzer/FuzzerMain.cpp:20:10
    #16 0x7f0f701a082f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #17 0x41e928 in _start (/out/fuzz-dhcp6-client+0x41e928)
yuwata pushed a commit that referenced this pull request Sep 29, 2018
==14==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020001c761a at pc 0x000000540abc bp 0x7ffd0caf2c50 sp 0x7ffd0caf2c48
READ of size 2 at 0x6020001c761a thread T0
    #0 0x540abb in client_parse_message /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:849:73
    #1 0x53f3bc in client_receive_advertise /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:1083:13
    #2 0x53d57f in client_receive_message /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:1182:21
    #3 0x7f71d8c3eeee in source_dispatch /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3042:21
    #4 0x7f71d8c3e431 in sd_event_dispatch /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3455:21
    #5 0x7f71d8c3fa8d in sd_event_run /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3512:21
    #6 0x531f2b in fuzz_client /work/build/../../src/systemd/src/fuzz/fuzz-dhcp6-client.c:44:9
    #7 0x531bc1 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-dhcp6-client.c:53:9
    #8 0x57bef8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:570:15
    #9 0x579d97 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:479:3
    #10 0x57dcc2 in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:707:19
    #11 0x580cd6 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:838:5
    #12 0x55e998 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:764:6
    #13 0x551a4c in main /src/libfuzzer/FuzzerMain.cpp:20:10
    #14 0x7f71d784182f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #15 0x41e928 in _start (/out/fuzz-dhcp6-client+0x41e928)
yuwata added a commit that referenced this pull request Oct 5, 2018
Since 205c085, Xorg (libinput) dumps core:
```
systemd-coredump[655]: Process 604 (Xorg) of user 0 dumped core.

                                       Stack trace of thread 610:
                                       #0  0x00007fc3aa21feab raise (libc.so.6)
                                       #1  0x00007fc3aa20a5b9 abort (libc.so.6)
                                       #2  0x00000000005a01a0 OsAbort (Xorg)
                                       #3  0x000000000047926c ddxGiveUp (Xorg)
                                       #4  0x00000000005a5cc8 AbortServer (Xorg)
                                       #5  0x00000000005a6b5d FatalError (Xorg)
                                       #6  0x000000000059d4e3 OsSigHandler (Xorg)
                                       #7  0x00007fc3aa5b9fb0 __restore_rt (libpthread.so.0)
                                       #8  0x00007fc3aa21feab raise (libc.so.6)
                                       #9  0x00007fc3aa20a5b9 abort (libc.so.6)
                                       #10 0x00007fc3ac9edd15 log_assert_failed_realm.constprop.56.cold.0 (libudev.so.1)
                                       #11 0x00007fc3ac9efe3f hashmap_free_no_clear (libudev.so.1)
                                       #12 0x00007fc3ac9f3311 hashmap_free_free_free (libudev.so.1)
                                       #13 0x00007fc3ac9fbe40 sd_device_unref (libudev.so.1)
                                       #14 0x00007fc3aca0094d udev_device_unref (libudev.so.1)
                                       #15 0x00007fc3a1efce39 evdev_device_destroy (libinput.so.10)
                                       #16 0x00007fc3a1ef6f05 libinput_device_unref (libinput.so.10)
                                       #17 0x00007fc3a1ef87c3 libinput_event_destroy (libinput.so.10)
                                       #18 0x00007fc3a2143d30 xf86libinput_read_input (libinput_drv.so)
                                       #19 0x000000000059b8b7 InputReady (Xorg)
                                       #20 0x000000000059ded1 ospoll_wait (Xorg)
                                       #21 0x000000000059b6fe InputThreadDoWork (Xorg)
                                       #22 0x00007fc3aa5af594 start_thread (libpthread.so.0)
                                       #23 0x00007fc3aa2e2e6f __clone (libc.so.6)

                                       Stack trace of thread 604:
                                       #0  0x00007fc3aa2e318f epoll_wait (libc.so.6)
                                       #1  0x000000000059de8b ospoll_wait (Xorg)
                                       #2  0x0000000000596efc WaitForSomething (Xorg)
                                       #3  0x0000000000434c20 Dispatch (Xorg)
                                       #4  0x0000000000438f26 dix_main (Xorg)
                                       #5  0x00007fc3aa20c11b __libc_start_main (libc.so.6)
                                       #6  0x000000000042290a _start (Xorg)
```

This makes Hashmap or Set in libsystemd or libudev not use mempool.
Fixes the above issue.
yuwata pushed a commit that referenced this pull request Oct 22, 2018
A couple of changes:

1. Clearly name the drop-in entry files "Type #1", and the unified
   kernel images "Type #2", and be clearer that the latter is specific
   to UEFI.

2. Suffix all directory paths with a trailing "/" to clarify that these
   are directories. Also, enclose them all in ``.

3. Add introductory paragraph that explains that there is Type #1 and
   Type #2 and what they are about.

4. Explain that Type #2 is about signed UEFI SecureBoot.

5. Don't claim that $BOOT/loader/ contains really all files defined by
   the spec, because that's not true, Type #2 images are not located there
   after all.

Fixes: systemd#10399
yuwata pushed a commit that referenced this pull request Oct 23, 2018
This is useful for a couple of cases, I'm mostly interested in case #1:

1. Verifying "reasonable" values in a trivially scriptable way
2. Debugging unexpected time span parsing directly

Test Plan:

```
% build/systemd-analyze timespan 20
Original: 20
      μs: 20
   Human: 20us
% build/systemd-analyze timespan 20ms
Original: 20ms
      μs: 20000
   Human: 20ms
% build/systemd-analyze timespan 20z
Failed to parse time span '20z': Invalid argument
```
yuwata pushed a commit that referenced this pull request Nov 16, 2018
This is a follow-up to 8857fb9 that prevents the fuzzer from crashing with
```
==220==ERROR: AddressSanitizer: ABRT on unknown address 0x0000000000dc (pc 0x7ff4953c8428 bp 0x7ffcf66ec290 sp 0x7ffcf66ec128 T0)
SCARINESS: 10 (signal)
    #0 0x7ff4953c8427 in gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35427)
    #1 0x7ff4953ca029 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x37029)
    #2 0x7ff49666503a in log_assert_failed_realm /work/build/../../src/systemd/src/basic/log.c:805:9
    #3 0x7ff496614ecf in safe_close /work/build/../../src/systemd/src/basic/fd-util.c:66:17
    #4 0x548806 in server_done /work/build/../../src/systemd/src/journal/journald-server.c:2064:9
    #5 0x5349fa in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journald-kmsg.c:26:9
    #6 0x592755 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:571:15
    #7 0x590627 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:480:3
    #8 0x594432 in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:708:19
    #9 0x5973c6 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:839:5
    #10 0x574541 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:764:6
    #11 0x5675fc in main /src/libfuzzer/FuzzerMain.cpp:20:10
    #12 0x7ff4953b382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #13 0x420f58 in _start (/out/fuzz-journald-kmsg+0x420f58)
```
yuwata pushed a commit that referenced this pull request Jan 18, 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.
yuwata pushed a commit that referenced this pull request Jan 30, 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.
yuwata pushed a commit that referenced this pull request Mar 15, 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 systemd#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 ()
yuwata pushed a commit that referenced this pull request Oct 23, 2019
These offsets can be useful to decode stack traces through modules that don't
have symbol names. For example, with a simple test that crashes after calling
through several static functions, systemd-coredump reports this:

 Oct 17 : Process 640333 (a.out) of user 1000 dumped core.

          Stack trace of thread 640333:
          #0  0x00005562c2b9f11d n/a (/tmp/a.out)
          #1  0x00005562c2b9f12d n/a (/tmp/a.out)
          #2  0x00005562c2b9f139 n/a (/tmp/a.out)
          #3  0x00005562c2b9f145 n/a (/tmp/a.out)
          #4  0x00007fc768b39153 __libc_start_main (libc.so.6)
          #5  0x00005562c2b9f04e n/a (/tmp/a.out)

With this change:

          Stack trace of thread 666897:
          #0  0x0000555668fbe11d n/a (/tmp/a.out + 0x111d)
          #1  0x0000555668fbe12d n/a (/tmp/a.out + 0x112d)
          #2  0x0000555668fbe139 n/a (/tmp/a.out + 0x1139)
          #3  0x0000555668fbe145 n/a (/tmp/a.out + 0x1145)
          #4  0x00007f7b5c828153 __libc_start_main (libc.so.6 + 0x27153)
          #5  0x0000555668fbe04e n/a (/tmp/a.out + 0x104e)

Disassembling the test binary shows that these offsets line up:

 0000000000001119 <crash>:
     1119:      55                      push   %rbp
     111a:      48 89 e5                mov    %rsp,%rbp
     111d:      0f 0b                   ud2                 <---- #0

 000000000000111f <b>:
     111f:      55                      push   %rbp
     1120:      48 89 e5                mov    %rsp,%rbp
     1123:      b8 00 00 00 00          mov    $0x0,%eax
     1128:      e8 ec ff ff ff          callq  1119 <crash>
     112d:      90                      nop                 <---- #1
     112e:      5d                      pop    %rbp
     112f:      c3                      retq

 0000000000001130 <a>:
     1130:      55                      push   %rbp
     1131:      48 89 e5                mov    %rsp,%rbp
     1134:      e8 e6 ff ff ff          callq  111f <b>
     1139:      90                      nop                 <---- #2
     113a:      5d                      pop    %rbp
     113b:      c3                      retq

 000000000000113c <main>:
     113c:      55                      push   %rbp
     113d:      48 89 e5                mov    %rsp,%rbp
     1140:      e8 eb ff ff ff          callq  1130 <a>
     1145:      b8 00 00 00 00          mov    $0x0,%eax    <---- #3
     114a:      5d                      pop    %rbp
     114b:      c3                      retq
     114c:      0f 1f 40 00             nopl   0x0(%rax)

 (from libc.so.6)
 0000000000027060 <__libc_start_main>:
   27060:	f3 0f 1e fa          	endbr64
   27064:	41 56                	push   %r14
   27066:	31 c0                	xor    %eax,%eax
   [...]
   2714c:	48 8b 44 24 18       	mov    0x18(%rsp),%rax
   27151:	ff d0                	callq  *%rax
   27153:	89 c7                	mov    %eax,%edi    <---- #4
   27155:	e8 e6 76 01 00       	callq  3e840 <exit>
yuwata pushed a commit that referenced this pull request May 7, 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#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#6119
yuwata pushed a commit that referenced this pull request May 20, 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
```
yuwata pushed a commit that referenced this pull request May 28, 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

```
yuwata pushed a commit that referenced this pull request Jun 23, 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)
yuwata pushed a commit that referenced this pull request Jun 25, 2020
…tches

AddressSanitizer:DEADLYSIGNAL
=================================================================
==12==ERROR: AddressSanitizer: ABRT on unknown address 0x00000000000c (pc 0x7f0a518b3428 bp 0x7fffa463bfd0 sp 0x7fffa463be68 T0)
SCARINESS: 10 (signal)
    #0 0x7f0a518b3428 in raise (/lib/x86_64-linux-gnu/libc.so.6+0x35428)
    #1 0x7f0a518b5029 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x37029)
    #2 0x7f0a52ca635a in log_assert_failed_realm /work/build/../../src/systemd/src/basic/log.c:819:9
    #3 0x4eea92 in config_parse_wireguard_endpoint /work/build/../../src/systemd/src/network/netdev/wireguard.c:808:9
    #4 0x7f0a52b2f74e in next_assignment /work/build/../../src/systemd/src/shared/conf-parser.c:133:32
    #5 0x7f0a52b2954e in parse_line /work/build/../../src/systemd/src/shared/conf-parser.c:242:16
    #6 0x7f0a52b28911 in config_parse /work/build/../../src/systemd/src/shared/conf-parser.c:377:21
    #7 0x7f0a52b29ec6 in config_parse_many_files /work/build/../../src/systemd/src/shared/conf-parser.c:439:21
    #8 0x7f0a52b2a5a6 in config_parse_many /work/build/../../src/systemd/src/shared/conf-parser.c:507:16
    #9 0x4d8d6c in netdev_load_one /work/build/../../src/systemd/src/network/netdev/netdev.c:732:13
    #10 0x4d3e2b in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/network/fuzz-netdev-parser.c:23:16
    #11 0x6b3266 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:558:15
    #12 0x6af860 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:470:3
    #13 0x6b6970 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:770:7
    #14 0x6b7376 in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:799:3
    #15 0x67573f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:846:6
    #16 0x667097 in main /src/libfuzzer/FuzzerMain.cpp:19:10
    #17 0x7f0a5189e82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #18 0x4295a8 in _start (out/fuzz-netdev-parser+0x4295a8)

DEDUP_TOKEN: raise--abort--log_assert_failed_realm
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: ABRT (/lib/x86_64-linux-gnu/libc.so.6+0x35428) in raise
==12==ABORTING
yuwata pushed a commit that referenced this pull request Aug 26, 2020
"Linux" conflicts /efi/Linux when /efi is the install location.
/efi/Linux is already reserved for unified kernel images so we can't use
it for type #1 images. Instead, we use "Default".
yuwata pushed a commit that referenced this pull request Sep 19, 2020
This lets the libc/xcrypt allocate as much storage area as it needs.
Should fix systemd#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?
yuwata pushed a commit that referenced this pull request Feb 11, 2021
Coverity says:
CID 1446387 (#1 of 1): Bad bit shift operation (BAD_SHIFT)
8. negative_shift: In expression 1U << (int)cmd, shifting by a negative amount
has undefined behavior. The shift amount, cmd, is -22.

I don't think there's any issue, unless we forget to set token->data
appropriately. Let's add an assert.
yuwata pushed a commit that referenced this pull request Aug 4, 2021
The current pattern '#' triggers on the openSUSE kernel version that is
printed early during boot when no actual prompt is ready
> [    0.000000] Linux version 5.12.10-1-default (geeko@buildhost) (gcc (SUSE Linux) 11.1.1 20210510 [revision 23855a176609fe8dda6abaf2b21846b4517966eb], GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.36.1.20210326-4) #1 SMP Fri Jun 11 05:05:06 UTC 2021 (b92eaf7)

Instead wait for pattern that: a) should have fewer false positives, b)
still be with working on distro shells:

openSUSE (red color)
^[[1m^[[31mimage:~ #^[[m^O

arch
[root@image ~]#

debian
root@image:~#

ubuntu
root@image:~#

fedora
[root@image ~]#
yuwata pushed a commit that referenced this pull request May 27, 2022
Provide some coverage for systemd#23481.

Without 794da5a:
```
[   34.730815] testsuite-29.sh[600]: + portablectl detach --now --runtime --enable /tmp/rootdir minimal-app0
         Stopping minimal-app0-foo.service...
[  OK  ] Stopped minimal-app0-foo.service.
         Stopping minimal-app0.service...
[  OK  ] Stopped minimal-app0.service.
[   34.878050] testsuite-29.sh[1383]: =================================================================
[   34.878421] testsuite-29.sh[1383]: ==1383==ERROR: LeakSanitizer: detected memory leaks
[   34.878784] testsuite-29.sh[1383]: Direct leak of 48 byte(s) in 2 object(s) allocated from:
[   34.879174] testsuite-29.sh[1383]:     #0 0x7fdf9c8b0f8c in reallocarray (/lib64/libasan.so.6+0xaef8c)
[   34.879554] testsuite-29.sh[1383]:     #1 0x7fdf9b4270f5 in unit_file_changes_add ../src/shared/install.c:282
[   34.879926] testsuite-29.sh[1383]:     #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688
[   34.880267] testsuite-29.sh[1383]:     #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582
[   34.880673] testsuite-29.sh[1383]:     #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810
[   34.881064] testsuite-29.sh[1383]:     #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924
[   34.881493] testsuite-29.sh[1383]:     #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103
[   34.881953] testsuite-29.sh[1383]:     #7 0x41604a in run ../src/portable/portablectl.c:1427
[   34.882459] testsuite-29.sh[1383]:     #8 0x416106 in main ../src/portable/portablectl.c:1430
[   34.882947] testsuite-29.sh[1383]:     #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f)
[   34.883368] testsuite-29.sh[1383]: Indirect leak of 104 byte(s) in 2 object(s) allocated from:
[   34.883732] testsuite-29.sh[1383]:     #0 0x7fdf9c85b8f7 in strdup (/lib64/libasan.so.6+0x598f7)
[   34.884089] testsuite-29.sh[1383]:     #1 0x7fdf9b4271aa in unit_file_changes_add ../src/shared/install.c:288
[   34.884508] testsuite-29.sh[1383]:     #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688
[   34.884926] testsuite-29.sh[1383]:     #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582
[   34.885307] testsuite-29.sh[1383]:     #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810
[   34.885647] testsuite-29.sh[1383]:     #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924
[   34.885987] testsuite-29.sh[1383]:     #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103
[   34.886271] testsuite-29.sh[1383]:     #7 0x41604a in run ../src/portable/portablectl.c:1427
[   34.886557] testsuite-29.sh[1383]:     #8 0x416106 in main ../src/portable/portablectl.c:1430
[   34.886892] testsuite-29.sh[1383]:     #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f)
[   34.887187] testsuite-29.sh[1383]: Indirect leak of 2 byte(s) in 2 object(s) allocated from:
[   34.887520] testsuite-29.sh[1383]:     #0 0x7fdf9c85b8f7 in strdup (/lib64/libasan.so.6+0x598f7)
[   34.887797] testsuite-29.sh[1383]:     #1 0x7fdf9b427249 in unit_file_changes_add ../src/shared/install.c:296
[   34.888117] testsuite-29.sh[1383]:     #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688
[   34.888434] testsuite-29.sh[1383]:     #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582
[   34.888693] testsuite-29.sh[1383]:     #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810
[   34.888990] testsuite-29.sh[1383]:     #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924
[   34.889254] testsuite-29.sh[1383]:     #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103
[   34.889580] testsuite-29.sh[1383]:     #7 0x41604a in run ../src/portable/portablectl.c:1427
[   34.889877] testsuite-29.sh[1383]:     #8 0x416106 in main ../src/portable/portablectl.c:1430
[   34.890193] testsuite-29.sh[1383]:     #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f)
[   34.890482] testsuite-29.sh[1383]: SUMMARY: AddressSanitizer: 154 byte(s) leaked in 6 allocation(s).

```

With 794da5a:
```
[  OK  ] Started minimal-app0.service.
[   36.794367] testsuite-29.sh[600]: + portablectl detach --now --runtime --enable /tmp/rootdir minimal-app0
         Stopping minimal-app0-foo.service...
[  OK  ] Stopped minimal-app0-foo.service.
         Stopping minimal-app0.service...
[  OK  ] Stopped minimal-app0.service.
[   36.851251] testsuite-29.sh[600]: + umount /tmp/rootdir
```
yuwata pushed a commit that referenced this pull request May 29, 2022
We said "`$BOOT/loader/` is the directory containing all files needed
for Type #1 entries" which is blatantly wrong. And also saying that we
define two directories, /loader and /loader/entries, but only ever defining
the second one was not very consistent.

Instead, let's say that /loader/ is for "boot loader configuration", and
/loader/entries has the snippets. A new section about /<entry-token>/<version>/
is added. This is described as the "recommended layout for additional files".

Also, we said that ID= should be used in the file name, but in fact it
wasn't in the example that was given, and afaik, nobody ever did that. So
this part is reduced to say "kernel version (as returned by `uname -r`,
including the OS identifier)". AFAIK, all distros include some form of
OS identifier in the version, so this should be good enough.

Since we now don't depend on autodetection (e.g. with entry-token and layout
configured), the installed doesn't need to always create /loader/entries and
things will still work. So don't say that the installer needs to create it.

Part of the discussion is moved to the Discussion section.

Overall, this brings the specification more in line with actual practice.
yuwata pushed a commit that referenced this pull request May 29, 2022
Provide some coverage for systemd#23481.

Without 794da5a:
```
[   34.730815] testsuite-29.sh[600]: + portablectl detach --now --runtime --enable /tmp/rootdir minimal-app0
         Stopping minimal-app0-foo.service...
[  OK  ] Stopped minimal-app0-foo.service.
         Stopping minimal-app0.service...
[  OK  ] Stopped minimal-app0.service.
[   34.878050] testsuite-29.sh[1383]: =================================================================
[   34.878421] testsuite-29.sh[1383]: ==1383==ERROR: LeakSanitizer: detected memory leaks
[   34.878784] testsuite-29.sh[1383]: Direct leak of 48 byte(s) in 2 object(s) allocated from:
[   34.879174] testsuite-29.sh[1383]:     #0 0x7fdf9c8b0f8c in reallocarray (/lib64/libasan.so.6+0xaef8c)
[   34.879554] testsuite-29.sh[1383]:     #1 0x7fdf9b4270f5 in unit_file_changes_add ../src/shared/install.c:282
[   34.879926] testsuite-29.sh[1383]:     #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688
[   34.880267] testsuite-29.sh[1383]:     #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582
[   34.880673] testsuite-29.sh[1383]:     #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810
[   34.881064] testsuite-29.sh[1383]:     #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924
[   34.881493] testsuite-29.sh[1383]:     #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103
[   34.881953] testsuite-29.sh[1383]:     #7 0x41604a in run ../src/portable/portablectl.c:1427
[   34.882459] testsuite-29.sh[1383]:     #8 0x416106 in main ../src/portable/portablectl.c:1430
[   34.882947] testsuite-29.sh[1383]:     #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f)
[   34.883368] testsuite-29.sh[1383]: Indirect leak of 104 byte(s) in 2 object(s) allocated from:
[   34.883732] testsuite-29.sh[1383]:     #0 0x7fdf9c85b8f7 in strdup (/lib64/libasan.so.6+0x598f7)
[   34.884089] testsuite-29.sh[1383]:     #1 0x7fdf9b4271aa in unit_file_changes_add ../src/shared/install.c:288
[   34.884508] testsuite-29.sh[1383]:     #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688
[   34.884926] testsuite-29.sh[1383]:     #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582
[   34.885307] testsuite-29.sh[1383]:     #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810
[   34.885647] testsuite-29.sh[1383]:     #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924
[   34.885987] testsuite-29.sh[1383]:     #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103
[   34.886271] testsuite-29.sh[1383]:     #7 0x41604a in run ../src/portable/portablectl.c:1427
[   34.886557] testsuite-29.sh[1383]:     #8 0x416106 in main ../src/portable/portablectl.c:1430
[   34.886892] testsuite-29.sh[1383]:     #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f)
[   34.887187] testsuite-29.sh[1383]: Indirect leak of 2 byte(s) in 2 object(s) allocated from:
[   34.887520] testsuite-29.sh[1383]:     #0 0x7fdf9c85b8f7 in strdup (/lib64/libasan.so.6+0x598f7)
[   34.887797] testsuite-29.sh[1383]:     #1 0x7fdf9b427249 in unit_file_changes_add ../src/shared/install.c:296
[   34.888117] testsuite-29.sh[1383]:     #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688
[   34.888434] testsuite-29.sh[1383]:     #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582
[   34.888693] testsuite-29.sh[1383]:     #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810
[   34.888990] testsuite-29.sh[1383]:     #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924
[   34.889254] testsuite-29.sh[1383]:     #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103
[   34.889580] testsuite-29.sh[1383]:     #7 0x41604a in run ../src/portable/portablectl.c:1427
[   34.889877] testsuite-29.sh[1383]:     #8 0x416106 in main ../src/portable/portablectl.c:1430
[   34.890193] testsuite-29.sh[1383]:     #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f)
[   34.890482] testsuite-29.sh[1383]: SUMMARY: AddressSanitizer: 154 byte(s) leaked in 6 allocation(s).

```

With 794da5a:
```
[  OK  ] Started minimal-app0.service.
[   36.794367] testsuite-29.sh[600]: + portablectl detach --now --runtime --enable /tmp/rootdir minimal-app0
         Stopping minimal-app0-foo.service...
[  OK  ] Stopped minimal-app0-foo.service.
         Stopping minimal-app0.service...
[  OK  ] Stopped minimal-app0.service.
[   36.851251] testsuite-29.sh[600]: + umount /tmp/rootdir
```
yuwata pushed a commit that referenced this pull request May 29, 2022
Provide some coverage for systemd#23481.

Without 794da5a:
```
[   34.730815] testsuite-29.sh[600]: + portablectl detach --now --runtime --enable /tmp/rootdir minimal-app0
         Stopping minimal-app0-foo.service...
[  OK  ] Stopped minimal-app0-foo.service.
         Stopping minimal-app0.service...
[  OK  ] Stopped minimal-app0.service.
[   34.878050] testsuite-29.sh[1383]: =================================================================
[   34.878421] testsuite-29.sh[1383]: ==1383==ERROR: LeakSanitizer: detected memory leaks
[   34.878784] testsuite-29.sh[1383]: Direct leak of 48 byte(s) in 2 object(s) allocated from:
[   34.879174] testsuite-29.sh[1383]:     #0 0x7fdf9c8b0f8c in reallocarray (/lib64/libasan.so.6+0xaef8c)
[   34.879554] testsuite-29.sh[1383]:     #1 0x7fdf9b4270f5 in unit_file_changes_add ../src/shared/install.c:282
[   34.879926] testsuite-29.sh[1383]:     #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688
[   34.880267] testsuite-29.sh[1383]:     #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582
[   34.880673] testsuite-29.sh[1383]:     #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810
[   34.881064] testsuite-29.sh[1383]:     #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924
[   34.881493] testsuite-29.sh[1383]:     #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103
[   34.881953] testsuite-29.sh[1383]:     #7 0x41604a in run ../src/portable/portablectl.c:1427
[   34.882459] testsuite-29.sh[1383]:     #8 0x416106 in main ../src/portable/portablectl.c:1430
[   34.882947] testsuite-29.sh[1383]:     #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f)
[   34.883368] testsuite-29.sh[1383]: Indirect leak of 104 byte(s) in 2 object(s) allocated from:
[   34.883732] testsuite-29.sh[1383]:     #0 0x7fdf9c85b8f7 in strdup (/lib64/libasan.so.6+0x598f7)
[   34.884089] testsuite-29.sh[1383]:     #1 0x7fdf9b4271aa in unit_file_changes_add ../src/shared/install.c:288
[   34.884508] testsuite-29.sh[1383]:     #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688
[   34.884926] testsuite-29.sh[1383]:     #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582
[   34.885307] testsuite-29.sh[1383]:     #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810
[   34.885647] testsuite-29.sh[1383]:     #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924
[   34.885987] testsuite-29.sh[1383]:     #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103
[   34.886271] testsuite-29.sh[1383]:     #7 0x41604a in run ../src/portable/portablectl.c:1427
[   34.886557] testsuite-29.sh[1383]:     #8 0x416106 in main ../src/portable/portablectl.c:1430
[   34.886892] testsuite-29.sh[1383]:     #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f)
[   34.887187] testsuite-29.sh[1383]: Indirect leak of 2 byte(s) in 2 object(s) allocated from:
[   34.887520] testsuite-29.sh[1383]:     #0 0x7fdf9c85b8f7 in strdup (/lib64/libasan.so.6+0x598f7)
[   34.887797] testsuite-29.sh[1383]:     #1 0x7fdf9b427249 in unit_file_changes_add ../src/shared/install.c:296
[   34.888117] testsuite-29.sh[1383]:     #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688
[   34.888434] testsuite-29.sh[1383]:     #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582
[   34.888693] testsuite-29.sh[1383]:     #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810
[   34.888990] testsuite-29.sh[1383]:     #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924
[   34.889254] testsuite-29.sh[1383]:     #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103
[   34.889580] testsuite-29.sh[1383]:     #7 0x41604a in run ../src/portable/portablectl.c:1427
[   34.889877] testsuite-29.sh[1383]:     #8 0x416106 in main ../src/portable/portablectl.c:1430
[   34.890193] testsuite-29.sh[1383]:     #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f)
[   34.890482] testsuite-29.sh[1383]: SUMMARY: AddressSanitizer: 154 byte(s) leaked in 6 allocation(s).

```

With 794da5a:
```
[  OK  ] Started minimal-app0.service.
[   36.794367] testsuite-29.sh[600]: + portablectl detach --now --runtime --enable /tmp/rootdir minimal-app0
         Stopping minimal-app0-foo.service...
[  OK  ] Stopped minimal-app0-foo.service.
         Stopping minimal-app0.service...
[  OK  ] Stopped minimal-app0.service.
[   36.851251] testsuite-29.sh[600]: + umount /tmp/rootdir
```
yuwata pushed a commit that referenced this pull request May 30, 2022
Provide some coverage for systemd#23481.

Without 794da5a:
```
[   34.730815] testsuite-29.sh[600]: + portablectl detach --now --runtime --enable /tmp/rootdir minimal-app0
         Stopping minimal-app0-foo.service...
[  OK  ] Stopped minimal-app0-foo.service.
         Stopping minimal-app0.service...
[  OK  ] Stopped minimal-app0.service.
[   34.878050] testsuite-29.sh[1383]: =================================================================
[   34.878421] testsuite-29.sh[1383]: ==1383==ERROR: LeakSanitizer: detected memory leaks
[   34.878784] testsuite-29.sh[1383]: Direct leak of 48 byte(s) in 2 object(s) allocated from:
[   34.879174] testsuite-29.sh[1383]:     #0 0x7fdf9c8b0f8c in reallocarray (/lib64/libasan.so.6+0xaef8c)
[   34.879554] testsuite-29.sh[1383]:     #1 0x7fdf9b4270f5 in unit_file_changes_add ../src/shared/install.c:282
[   34.879926] testsuite-29.sh[1383]:     #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688
[   34.880267] testsuite-29.sh[1383]:     #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582
[   34.880673] testsuite-29.sh[1383]:     #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810
[   34.881064] testsuite-29.sh[1383]:     #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924
[   34.881493] testsuite-29.sh[1383]:     #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103
[   34.881953] testsuite-29.sh[1383]:     #7 0x41604a in run ../src/portable/portablectl.c:1427
[   34.882459] testsuite-29.sh[1383]:     #8 0x416106 in main ../src/portable/portablectl.c:1430
[   34.882947] testsuite-29.sh[1383]:     #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f)
[   34.883368] testsuite-29.sh[1383]: Indirect leak of 104 byte(s) in 2 object(s) allocated from:
[   34.883732] testsuite-29.sh[1383]:     #0 0x7fdf9c85b8f7 in strdup (/lib64/libasan.so.6+0x598f7)
[   34.884089] testsuite-29.sh[1383]:     #1 0x7fdf9b4271aa in unit_file_changes_add ../src/shared/install.c:288
[   34.884508] testsuite-29.sh[1383]:     #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688
[   34.884926] testsuite-29.sh[1383]:     #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582
[   34.885307] testsuite-29.sh[1383]:     #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810
[   34.885647] testsuite-29.sh[1383]:     #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924
[   34.885987] testsuite-29.sh[1383]:     #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103
[   34.886271] testsuite-29.sh[1383]:     #7 0x41604a in run ../src/portable/portablectl.c:1427
[   34.886557] testsuite-29.sh[1383]:     #8 0x416106 in main ../src/portable/portablectl.c:1430
[   34.886892] testsuite-29.sh[1383]:     #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f)
[   34.887187] testsuite-29.sh[1383]: Indirect leak of 2 byte(s) in 2 object(s) allocated from:
[   34.887520] testsuite-29.sh[1383]:     #0 0x7fdf9c85b8f7 in strdup (/lib64/libasan.so.6+0x598f7)
[   34.887797] testsuite-29.sh[1383]:     #1 0x7fdf9b427249 in unit_file_changes_add ../src/shared/install.c:296
[   34.888117] testsuite-29.sh[1383]:     #2 0x7fdf9b2ad9e5 in bus_deserialize_and_dump_unit_file_changes ../src/shared/bus-unit-util.c:2688
[   34.888434] testsuite-29.sh[1383]:     #3 0x40bc27 in maybe_enable_disable ../src/portable/portablectl.c:582
[   34.888693] testsuite-29.sh[1383]:     #4 0x40ef56 in maybe_stop_disable ../src/portable/portablectl.c:810
[   34.888990] testsuite-29.sh[1383]:     #5 0x410bc2 in detach_image ../src/portable/portablectl.c:924
[   34.889254] testsuite-29.sh[1383]:     #6 0x7fdf9b5df424 in dispatch_verb ../src/shared/verbs.c:103
[   34.889580] testsuite-29.sh[1383]:     #7 0x41604a in run ../src/portable/portablectl.c:1427
[   34.889877] testsuite-29.sh[1383]:     #8 0x416106 in main ../src/portable/portablectl.c:1430
[   34.890193] testsuite-29.sh[1383]:     #9 0x7fdf99d5de8f in __libc_start_call_main (/lib64/libc.so.6+0x44e8f)
[   34.890482] testsuite-29.sh[1383]: SUMMARY: AddressSanitizer: 154 byte(s) leaked in 6 allocation(s).

```

With 794da5a:
```
[  OK  ] Started minimal-app0.service.
[   36.794367] testsuite-29.sh[600]: + portablectl detach --now --runtime --enable /tmp/rootdir minimal-app0
         Stopping minimal-app0-foo.service...
[  OK  ] Stopped minimal-app0-foo.service.
         Stopping minimal-app0.service...
[  OK  ] Stopped minimal-app0.service.
[   36.851251] testsuite-29.sh[600]: + umount /tmp/rootdir
```
yuwata pushed a commit that referenced this pull request Jun 9, 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)
yuwata pushed a commit that referenced this pull request Jun 15, 2022
Fixes: CID#1469711

CID 1469711 (#1 of 1): Uninitialized scalar variable (UNINIT)
14. uninit_use: Using uninitialized value we_detached.
yuwata pushed a commit that referenced this pull request Jun 15, 2022
Fixes: CID#1469712

CID 1469712 (#1 of 1): Unused value (UNUSED_VALUE)
returned_value: Assigning value from sd_id128_from_string(word + 2, &boot_id) to r here,
but that stored value is overwritten before it can be used.
yuwata pushed a commit that referenced this pull request Aug 4, 2022
Report whether the devicetree + sort-key boot loader spec type #1
fields are supported, and whether the "@saved" pseudo-entry is
supported.

Strictly speaking, thes features have been added in versions that are
already released (250+), so by adding this those version even though
they support the features will be considered not supporting them, but
that should be OK (the opposite would be a problem though, i.e. if we'd
assume a boot loader had a feature it actually does not).

These three features are features relevant to userspace, as it allows
userspace to tweak/genereate BLS entries or set EFI vars correctly.
Other features (i.e. that have no impliciations to userspace) are not
reported.
yuwata pushed a commit that referenced this pull request Sep 2, 2022
Inspired by systemd#23913, let's complain if people use paths with ".."
in Type #1 bootspec entries.

Let's prefix all paths with "/" if it is missing.

Let's simplify all paths.

let's refuse paths/warn with "..".

Fixes: systemd#23913
yuwata added a commit that referenced this pull request Sep 3, 2022
Fixes the following 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)
---
yuwata added a commit that referenced this pull request Sep 3, 2022
This is a workaround for an issue in the memory sanitizer.
If a function is called with too many arguments, then the sanitizer
triggers the following false-positive warning:

==349==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f8b247134a7 in json_buildv /work/build/../../src/systemd/src/shared/json.c:3213:17
    #1 0x7f8b24714231 in json_build /work/build/../../src/systemd/src/shared/json.c:4117:13
    #2 0x7f8b24487fa5 in show_boot_entries /work/build/../../src/systemd/src/shared/bootspec.c:1424:29
    #3 0x4a6a1b in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-bootspec.c:119:16
    #4 0x4c6693 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
    #5 0x4c5e7a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
    #6 0x4c7ce4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:826:7
    #7 0x4c7f19 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:857:3
    #8 0x4b757f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
    #9 0x4e0bd2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #10 0x7f8b23ead082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #11 0x41f69d in _start (build-out/fuzz-bootspec+0x41f69d)

Follow-up for systemd#24541.
Fixes systemd#24551.
yuwata added a commit that referenced this pull request Sep 3, 2022
This is a workaround for an issue in the memory sanitizer.
If a function is called with too many arguments, then the sanitizer
triggers the following false-positive warning:

==349==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f8b247134a7 in json_buildv /work/build/../../src/systemd/src/shared/json.c:3213:17
    #1 0x7f8b24714231 in json_build /work/build/../../src/systemd/src/shared/json.c:4117:13
    #2 0x7f8b24487fa5 in show_boot_entries /work/build/../../src/systemd/src/shared/bootspec.c:1424:29
    #3 0x4a6a1b in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-bootspec.c:119:16
    #4 0x4c6693 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
    #5 0x4c5e7a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
    #6 0x4c7ce4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:826:7
    #7 0x4c7f19 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:857:3
    #8 0x4b757f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
    #9 0x4e0bd2 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    #10 0x7f8b23ead082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #11 0x41f69d in _start (build-out/fuzz-bootspec+0x41f69d)

Follow-up for systemd#24541.
Fixes systemd#24551.
yuwata pushed a commit that referenced this pull request Oct 1, 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)
yuwata pushed a commit that referenced this pull request Oct 12, 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:
...
```
yuwata pushed a commit that referenced this pull request Oct 24, 2022
The test would fail when addresses were being removed in parallel. In general,
the check is only valid when the machine configuration is static, which in
general isn't true.

CentOS CI (Arch Linux) fails in TEST-02-UNITTESTS test-local-addresses:

10:38:05 (gdb) #0  0x00007f86260a164c in ?? () from /usr/lib/libc.so.6
10:38:05 No symbol table info available.
10:38:05 #1  0x00007f8626051958 in raise () from /usr/lib/libc.so.6
10:38:05 No symbol table info available.
10:38:05 #2  0x00007f862603b53d in abort () from /usr/lib/libc.so.6
10:38:05 No symbol table info available.
10:38:05 #3  0x00007f862639a755 in log_assert_failed (
10:38:05     text=text@entry=0x56180e56c03b "n == n_ipv4 + n_ipv6",
10:38:05     file=file@entry=0x56180e56c0d1 "src/test/test-local-addresses.c",
10:38:05     line=line@entry=45,
10:38:05     func=func@entry=0x56180e56c360 <__PRETTY_FUNCTION__.6> "test_local_addresses") at ../build/src/basic/log.c:853
10:38:05 No locals.
10:38:05 #4  0x000056180e56b77e in test_local_addresses ()
10:38:05     at ../build/src/test/test-local-addresses.c:45
10:38:05         a = 0x0
10:38:05         n = 234
10:38:05         n_ipv4 = 236
10:38:05         n_ipv6 = 7
10:38:05         __PRETTY_FUNCTION__ = "test_local_addresses"
10:38:05         __func__ = "test_local_addresses"
10:38:05 #5  0x000056180e56ba67 in run_test_table () at ../build/src/shared/tests.h:106
10:38:05         r = 0
10:38:05         t = 0x56180e56e010 <__unique_prefix_static_test_table_entry10>
10:38:05         __PRETTY_FUNCTION__ = <optimized out>
10:38:05         __func__ = "run_test_table"
10:38:05 #6  0x000056180e56bb2f in main (argc=1, argv=0x7ffc3a814808)
10:38:05     at ../build/src/test/test-local-addresses.c:81
10:38:05         _intro = 0x0
10:38:05         _outro = 0x0
10:38:05         _r = 0
10:38:05         _q = 0
10:38:05 (gdb)

The logs show that there's a huge number of private addresses, probably from
some other test running in parallel.
yuwata pushed a commit that referenced this pull request Nov 10, 2022
…ocale=

\#0  __strcmp_evex () at ../sysdeps/x86_64/multiarch/strcmp-evex.S:295
No locals.
\#1  0x0000557444eb172b in process_locale () at ../src/firstboot/firstboot.c:342
        etc_localeconf = 0x7ffd40217b80 "/root/root/etc/locale.conf"
        locales = {0x0, 0x0, 0x0}
        i = 0
        r = <optimized out>
        __PRETTY_FUNCTION__ = "process_locale"
        __func__ = "process_locale"
\#2  0x0000557444eaff93 in run (argv=0x7ffd40217d98, argc=3) at ../src/firstboot/firstboot.c:1401
        loop_device = 0x0
        unlink_dir = 0x0
        r = <optimized out>
        loop_device = <optimized out>
        unlink_dir = <optimized out>
        r = <optimized out>
        __func__ = <optimized out>
        __PRETTY_FUNCTION__ = <optimized out>
        enabled = <optimized out>
        _error = <optimized out>
        _level = <optimized out>
        _e = <optimized out>
        _level = <optimized out>
        _e = <optimized out>
\#3  main (argc=3, argv=0x7ffd40217d98) at ../src/firstboot/firstboot.c:1432
        r = <optimized out>
        __PRETTY_FUNCTION__ = "main"

Fixes systemd#25249
yuwata pushed a commit that referenced this pull request Nov 30, 2022
Currently the kernel-install man page only documents the bls layout for use
with the boot loader spec type #1. 90-loaderentry.install uses this layout to
generate loader entries and copy the kernel image and initrd to $BOOT.

This commit documents a second layout "uki" and adds 90-uki-copy.install,
which copies a UKI "uki.efi" from the staging area or any file with the .efi
extension given on the command line to
$BOOT/EFI/Linux/$ENTRY_TOKEN-$KERNEl_VERSION(+$TRIES).efi

This allows for both locally generated and distro-provided UKIs to be handled
by kernel-install.
yuwata pushed a commit that referenced this pull request Dec 5, 2022
```
../src/basic/hexdecoct.c:66:44: runtime error: applying zero offset to null pointer
    #0 0x7f6022650c44 in hexmem /home/vagrant/systemd/build-fuzzers/../src/basic/hexdecoct.c:66:44
    #1 0x577583 in dns_resource_record_to_string /home/vagrant/systemd/build-fuzzers/../src/resolve/resolved-dns-rr.c:1140:21
    #2 0x563669 in LLVMFuzzerTestOneInput /home/vagrant/systemd/build-fuzzers/../src/resolve/fuzz-resource-record.c:25:39
    #3 0x44d2a1 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-resource-record+0x44d2a1) (BuildId: 88135c111396e9441a475302ccabd2f9a58c7e89)
    #4 0x42d32f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-resource-record+0x42d32f) (BuildId: 88135c111396e9441a475302ccabd2f9a58c7e89)
    #5 0x434920 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/out/fuzz-resource-record+0x434920) (BuildId: 88135c111396e9441a475302ccabd2f9a58c7e89)
    #6 0x424006 in main (/home/vagrant/systemd/out/fuzz-resource-record+0x424006) (BuildId: 88135c111396e9441a475302ccabd2f9a58c7e89)
    #7 0x7f602142950f in __libc_start_call_main (/lib64/libc.so.6+0x2950f) (BuildId: 85c438f4ff93e21675ff174371c9c583dca00b2c)
    #8 0x7f60214295c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x295c8) (BuildId: 85c438f4ff93e21675ff174371c9c583dca00b2c)
    #9 0x424044 in _start (/home/vagrant/systemd/out/fuzz-resource-record+0x424044) (BuildId: 88135c111396e9441a475302ccabd2f9a58c7e89)

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/basic/hexdecoct.c:66:44 in
```
yuwata pushed a commit that referenced this pull request Jan 9, 2023
When built with ACL support, we might be processing a tmpfiles
entry where there's no cause for us to call parse_acls_from_arg,
then we get to the end of parse_line without having ever populated
i.{acl_access, acl_default}.

Then we pass a null pointer into acl_free().

From UBSAN w/ GCC 13.0.0_pre20230101:
```
$ systemd-tmpfiles --clean
/var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44:14: runtime error: applying non-zero offset 18446744073709551608 to null pointer
    #0 0x7f65d868b482 in acl_free /var/tmp/portage/sys-apps/acl-2.3.1-r1/work/acl-2.3.1/libacl/acl_free.c:44
    #1 0x55fe7e592249 in item_free_contents ../systemd-9999/src/tmpfiles/tmpfiles.c:2855
    #2 0x55fe7e5a347a in parse_line ../systemd-9999/src/tmpfiles/tmpfiles.c:3158
    #3 0x55fe7e5a347a in read_config_file ../systemd-9999/src/tmpfiles/tmpfiles.c:3897
    #4 0x55fe7e590c61 in read_config_files ../systemd-9999/src/tmpfiles/tmpfiles.c:3985
    #5 0x55fe7e590c61 in run ../systemd-9999/src/tmpfiles/tmpfiles.c:4157
    #6 0x55fe7e590c61 in main ../systemd-9999/src/tmpfiles/tmpfiles.c:4218
    #7 0x7f65d7ebe289  (/usr/lib64/libc.so.6+0x23289)
    #8 0x7f65d7ebe344 in __libc_start_main (/usr/lib64/libc.so.6+0x23344)
    #9 0x55fe7e591900 in _start (/usr/bin/systemd-tmpfiles+0x11900)
```
yuwata pushed a commit that referenced this pull request Mar 28, 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).
yuwata pushed a commit that referenced this pull request Mar 28, 2023
$ dd if=/dev/zero of=luks.img bs=1M count=64
$ echo 1231dfsd234d | cryptsetup luksFormat luks.img
$ build-san/systemd-cryptenroll luks.img
SLOT TYPE
   0 password

=================================================================
==640364==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 64 byte(s) in 1 object(s) allocated from:
    #0 0x7f43ffeb95b5 in __interceptor_realloc.part.0 (/lib64/libasan.so.8+0xb95b5)
    #1 0x7f43ff0a4f2f in greedy_realloc ../src/basic/alloc-util.c:70
    #2 0x404d9f in list_enrolled ../src/cryptenroll/cryptenroll-list.c:30
    #3 0x40f149 in run ../src/cryptenroll/cryptenroll.c:673
    #4 0x40f149 in main ../src/cryptenroll/cryptenroll.c:692
    #5 0x7f43fd64a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)

SUMMARY: AddressSanitizer: 64 byte(s) leaked in 1 allocation(s).
Aborted (core dumped)

Reported in systemd#27007.
yuwata pushed a commit that referenced this pull request May 14, 2023
+ machinectl image-status container1 container1 container0 container1 container2 container3 container4
 =================================================================
 ==1354==ERROR: LeakSanitizer: detected memory leaks
 Direct leak of 4704 byte(s) in 6 object(s) allocated from:
     #0 0x7fc3670ba097 in calloc (/lib64/libasan.so.8+0xba097)
     #1 0x7fc365e91e8e in message_from_header ../src/libsystemd/sd-bus/bus-message.c:372
     #2 0x7fc365e92dfd in bus_message_from_malloc ../src/libsystemd/sd-bus/bus-message.c:421
     #3 0x7fc365f089a8 in bus_socket_make_message ../src/libsystemd/sd-bus/bus-socket.c:1165
     #4 0x7fc365f0affe in bus_socket_read_message ../src/libsystemd/sd-bus/bus-socket.c:1294
     #5 0x7fc365f2db71 in bus_read_message ../src/libsystemd/sd-bus/sd-bus.c:2082
     #6 0x7fc365f33352 in sd_bus_call ../src/libsystemd/sd-bus/sd-bus.c:2483
     #7 0x7fc365e4da61 in sd_bus_call_methodv ../src/libsystemd/sd-bus/bus-convenience.c:183
     #8 0x7fc3658789e8 in bus_call_method ../src/shared/bus-locator.c:109
     #9 0x413b76 in show_image ../src/machine/machinectl.c:1014
     #10 0x7fc365c5c8cf in dispatch_verb ../src/shared/verbs.c:103
     #11 0x42e992 in machinectl_main ../src/machine/machinectl.c:2981
     #12 0x42ebbd in run ../src/machine/machinectl.c:3006
     #13 0x42ece3 in main ../src/machine/machinectl.c:3009
     #14 0x7fc36444a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
 Indirect leak of 666 byte(s) in 6 object(s) allocated from:
     #0 0x7fc3670b95b5 in __interceptor_realloc.part.0 (/lib64/libasan.so.8+0xb95b5)
     #1 0x7fc365f09822 in bus_socket_read_message ../src/libsystemd/sd-bus/bus-socket.c:1214
     #2 0x7fc365f2db71 in bus_read_message ../src/libsystemd/sd-bus/sd-bus.c:2082
     #3 0x7fc365f33352 in sd_bus_call ../src/libsystemd/sd-bus/sd-bus.c:2483
     #4 0x7fc365e4da61 in sd_bus_call_methodv ../src/libsystemd/sd-bus/bus-convenience.c:183
     #5 0x7fc3658789e8 in bus_call_method ../src/shared/bus-locator.c:109
     #6 0x413b76 in show_image ../src/machine/machinectl.c:1014
     #7 0x7fc365c5c8cf in dispatch_verb ../src/shared/verbs.c:103
     #8 0x42e992 in machinectl_main ../src/machine/machinectl.c:2981
     #9 0x42ebbd in run ../src/machine/machinectl.c:3006
     #10 0x42ece3 in main ../src/machine/machinectl.c:3009
     #11 0x7fc36444a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
 Indirect leak of 12 byte(s) in 6 object(s) allocated from:
     #0 0x7fc36707243b in strdup (/lib64/libasan.so.8+0x7243b)
     #1 0x7fc365ec1543 in message_parse_fields ../src/libsystemd/sd-bus/bus-message.c:4125
     #2 0x7fc365e93586 in bus_message_from_malloc ../src/libsystemd/sd-bus/bus-message.c:443
     #3 0x7fc365f089a8 in bus_socket_make_message ../src/libsystemd/sd-bus/bus-socket.c:1165
     #4 0x7fc365f0affe in bus_socket_read_message ../src/libsystemd/sd-bus/bus-socket.c:1294
     #5 0x7fc365f2db71 in bus_read_message ../src/libsystemd/sd-bus/sd-bus.c:2082
     #6 0x7fc365f33352 in sd_bus_call ../src/libsystemd/sd-bus/sd-bus.c:2483
     #7 0x7fc365e4da61 in sd_bus_call_methodv ../src/libsystemd/sd-bus/bus-convenience.c:183
     #8 0x7fc3658789e8 in bus_call_method ../src/shared/bus-locator.c:109
     #9 0x413b76 in show_image ../src/machine/machinectl.c:1014
     #10 0x7fc365c5c8cf in dispatch_verb ../src/shared/verbs.c:103
     #11 0x42e992 in machinectl_main ../src/machine/machinectl.c:2981
     #12 0x42ebbd in run ../src/machine/machinectl.c:3006
     #13 0x42ece3 in main ../src/machine/machinectl.c:3009
     #14 0x7fc36444a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
 SUMMARY: AddressSanitizer: 5382 byte(s) leaked in 18 allocation(s).
yuwata pushed a commit that referenced this pull request May 14, 2023
+ machinectl status long-running long-running long-running
=================================================================
==986==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1568 byte(s) in 2 object(s) allocated from:
    #0 0x7fe57caba097 in calloc (/lib64/libasan.so.8+0xba097)
    #1 0x7fe57b891e8e in message_from_header ../src/libsystemd/sd-bus/bus-message.c:372
    #2 0x7fe57b892dfd in bus_message_from_malloc ../src/libsystemd/sd-bus/bus-message.c:421
    #3 0x7fe57b9089a8 in bus_socket_make_message ../src/libsystemd/sd-bus/bus-socket.c:1165
    #4 0x7fe57b90affe in bus_socket_read_message ../src/libsystemd/sd-bus/bus-socket.c:1294
    #5 0x7fe57b92db71 in bus_read_message ../src/libsystemd/sd-bus/sd-bus.c:2082
    #6 0x7fe57b933352 in sd_bus_call ../src/libsystemd/sd-bus/sd-bus.c:2483
    #7 0x7fe57b84da61 in sd_bus_call_methodv ../src/libsystemd/sd-bus/bus-convenience.c:183
    #8 0x7fe57b2789e8 in bus_call_method ../src/shared/bus-locator.c:109
    #9 0x40f71c in show_machine ../src/machine/machinectl.c:713
    #10 0x7fe57b65c8cf in dispatch_verb ../src/shared/verbs.c:103
    #11 0x42e9ce in machinectl_main ../src/machine/machinectl.c:2980
    #12 0x42ebf9 in run ../src/machine/machinectl.c:3005
    #13 0x42ed1f in main ../src/machine/machinectl.c:3008
    #14 0x7fe579e4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
Indirect leak of 234 byte(s) in 2 object(s) allocated from:
    #0 0x7fe57cab95b5 in __interceptor_realloc.part.0 (/lib64/libasan.so.8+0xb95b5)
    #1 0x7fe57b909822 in bus_socket_read_message ../src/libsystemd/sd-bus/bus-socket.c:1214
    #2 0x7fe57b92db71 in bus_read_message ../src/libsystemd/sd-bus/sd-bus.c:2082
    #3 0x7fe57b933352 in sd_bus_call ../src/libsystemd/sd-bus/sd-bus.c:2483
    #4 0x7fe57b84da61 in sd_bus_call_methodv ../src/libsystemd/sd-bus/bus-convenience.c:183
    #5 0x7fe57b2789e8 in bus_call_method ../src/shared/bus-locator.c:109
    #6 0x40f71c in show_machine ../src/machine/machinectl.c:713
    #7 0x7fe57b65c8cf in dispatch_verb ../src/shared/verbs.c:103
    #8 0x42e9ce in machinectl_main ../src/machine/machinectl.c:2980
    #9 0x42ebf9 in run ../src/machine/machinectl.c:3005
    #10 0x42ed1f in main ../src/machine/machinectl.c:3008
    #11 0x7fe579e4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
Indirect leak of 4 byte(s) in 2 object(s) allocated from:
    #0 0x7fe57ca7243b in strdup (/lib64/libasan.so.8+0x7243b)
    #1 0x7fe57b8c1543 in message_parse_fields ../src/libsystemd/sd-bus/bus-message.c:4125
    #2 0x7fe57b893586 in bus_message_from_malloc ../src/libsystemd/sd-bus/bus-message.c:443
    #3 0x7fe57b9089a8 in bus_socket_make_message ../src/libsystemd/sd-bus/bus-socket.c:1165
    #4 0x7fe57b90affe in bus_socket_read_message ../src/libsystemd/sd-bus/bus-socket.c:1294
    #5 0x7fe57b92db71 in bus_read_message ../src/libsystemd/sd-bus/sd-bus.c:2082
    #6 0x7fe57b933352 in sd_bus_call ../src/libsystemd/sd-bus/sd-bus.c:2483
    #7 0x7fe57b84da61 in sd_bus_call_methodv ../src/libsystemd/sd-bus/bus-convenience.c:183
    #8 0x7fe57b2789e8 in bus_call_method ../src/shared/bus-locator.c:109
    #9 0x40f71c in show_machine ../src/machine/machinectl.c:713
    #10 0x7fe57b65c8cf in dispatch_verb ../src/shared/verbs.c:103
    #11 0x42e9ce in machinectl_main ../src/machine/machinectl.c:2980
    #12 0x42ebf9 in run ../src/machine/machinectl.c:3005
    #13 0x42ed1f in main ../src/machine/machinectl.c:3008
    #14 0x7fe579e4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
SUMMARY: AddressSanitizer: 1806 byte(s) leaked in 6 allocation(s).
yuwata pushed a commit that referenced this pull request May 16, 2023
When merging the settings we take the pointer to the array of extra
devices, but don't reset the array counter to zero. This later leads to
a NULL pointer dereference, where device_node_array_free() attempts to
loop over a NULL pointer:

+ systemd-nspawn --oci-bundle=/var/lib/machines/testsuite-13.oci-bundle.Npo
 ../src/nspawn/nspawn-settings.c:118:29: runtime error: member access within null pointer of type 'struct DeviceNode'
     #0 0x4b91ee in device_node_array_free ../src/nspawn/nspawn-settings.c:118
     #1 0x4ba42a in settings_free ../src/nspawn/nspawn-settings.c:161
     #2 0x410b79 in settings_freep ../src/nspawn/nspawn-settings.h:249
     #3 0x446ce8 in load_oci_bundle ../src/nspawn/nspawn.c:4733
     #4 0x44ff42 in run ../src/nspawn/nspawn.c:5476
     #5 0x455296 in main ../src/nspawn/nspawn.c:5919
     #6 0x7f0cb7a4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
     #7 0x7f0cb7a4a5c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x275c8)
     #8 0x40d284 in _start (/usr/bin/systemd-nspawn+0x40d284)
 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/nspawn/nspawn-settings.c:118:29 in

Also, add an appropriate assert to catch such issues in the future.
yuwata pushed a commit that referenced this pull request May 16, 2023
Otherwise hilarity ensues:

 AddressSanitizer:DEADLYSIGNAL
 =================================================================
 ==722==ERROR: AddressSanitizer: SEGV on unknown address 0xffffffff00000000 (pc 0x7f8d50ca9ffb bp 0x7fff11b0d4a0 sp 0x7fff11b0cc30 T0)
 ==722==The signal is caused by a READ memory access.
     #0 0x7f8d50ca9ffb in __interceptor_strcmp.part.0 (/lib64/libasan.so.8+0xa9ffb)
     #1 0x7f8d4f9cf5a1 in strcmp_ptr ../src/fundamental/string-util-fundamental.h:33
     #2 0x7f8d4f9cf5f8 in streq_ptr ../src/fundamental/string-util-fundamental.h:46
     #3 0x7f8d4f9d74d2 in free_and_strdup ../src/basic/string-util.c:948
     #4 0x49139a in free_and_strdup_warn ../src/basic/string-util.h:197
     #5 0x4923eb in oci_absolute_path ../src/nspawn/nspawn-oci.c:139
     #6 0x7f8d4f6bd359 in json_dispatch ../src/shared/json.c:4395
     #7 0x4a8831 in oci_hooks_array ../src/nspawn/nspawn-oci.c:2089
     #8 0x7f8d4f6bd359 in json_dispatch ../src/shared/json.c:4395
     #9 0x4a8b56 in oci_hooks ../src/nspawn/nspawn-oci.c:2112
     #10 0x7f8d4f6bd359 in json_dispatch ../src/shared/json.c:4395
     #11 0x4aa298 in oci_load ../src/nspawn/nspawn-oci.c:2197
     #12 0x446cec in load_oci_bundle ../src/nspawn/nspawn.c:4744
     #13 0x44ffa7 in run ../src/nspawn/nspawn.c:5477
     #14 0x4552fb in main ../src/nspawn/nspawn.c:5920
     #15 0x7f8d4e04a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
     #16 0x7f8d4e04a5c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x275c8)
     #17 0x40d284 in _start (/usr/bin/systemd-nspawn+0x40d284)
 AddressSanitizer can not provide additional info.
 SUMMARY: AddressSanitizer: SEGV (/lib64/libasan.so.8+0xa9ffb) in __interceptor_strcmp.part.0
 ==722==ABORTING
yuwata pushed a commit that referenced this pull request May 16, 2023
Whoopsie.

=================================================================
==3789231==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000051d0b8 at pc 0x7f70850bc904 bp 0x7ffd9bbdf660 sp 0x7ffd9bbdf658
READ of size 8 at 0x00000051d0b8 thread T0
    #0 0x7f70850bc903 in json_dispatch ../src/shared/json.c:4347
    #1 0x4a5b54 in oci_seccomp_syscalls ../src/nspawn/nspawn-oci.c:1838
    #2 0x7f70850bd359 in json_dispatch ../src/shared/json.c:4395
    #3 0x4a668c in oci_seccomp ../src/nspawn/nspawn-oci.c:1905
    #4 0x7f70850bd359 in json_dispatch ../src/shared/json.c:4395
    #5 0x4a7d8c in oci_linux ../src/nspawn/nspawn-oci.c:2030
    #6 0x7f70850bd359 in json_dispatch ../src/shared/json.c:4395
    #7 0x4aa31c in oci_load ../src/nspawn/nspawn-oci.c:2198
    #8 0x446cec in load_oci_bundle ../src/nspawn/nspawn.c:4744
    #9 0x44ffa7 in run ../src/nspawn/nspawn.c:5477
    #10 0x4552fb in main ../src/nspawn/nspawn.c:5920
    #11 0x7f7083a4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
    #12 0x7f7083a4a5c8 in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x275c8)
    #13 0x40d284 in _start (/home/fsumsal/repos/@systemd/systemd/build-san/systemd-nspawn+0x40d284)

0x00000051d0b8 is located 40 bytes to the left of global variable 'bus_standard_errors_copy_0' defined in '../src/libsystemd/sd-bus/bus-error.h:57:1' (0x51d0e0) of size 8
0x00000051d0b8 is located 0 bytes to the right of global variable 'table' defined in '../src/nspawn/nspawn-oci.c:1829:43' (0x51d040) of size 120
SUMMARY: AddressSanitizer: global-buffer-overflow ../src/shared/json.c:4347 in json_dispatch
Shadow bytes around the buggy address:
  0x00008009b9c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00008009b9d0: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x00008009b9e0: 00 00 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x00008009b9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00008009ba00: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
=>0x00008009ba10: 00 00 00 00 00 00 00[f9]f9 f9 f9 f9 00 f9 f9 f9
  0x00008009ba20: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
  0x00008009ba30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00008009ba40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00008009ba50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x00008009ba60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==3789231==ABORTING
yuwata pushed a commit that referenced this pull request May 21, 2023
In case one of the allocations fails.

For example:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==17==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fb352a476e5 bp 0x7ffe45154850 sp 0x7ffe45154008 T0)
==17==The signal is caused by a READ memory access.
==17==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
    #0 0x7fb352a476e5  (/lib/x86_64-linux-gnu/libc.so.6+0x1886e5) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #1 0x435878 in __interceptor_strlen /src/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc
    #2 0x4de1e4 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-calendarspec.c:20:21
    #3 0x4deea8 in NaloFuzzerTestOneInput (/build/fuzz-calendarspec+0x4deea8)
    #4 0x4fde33 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
    #5 0x4fd61a 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 0x4fece9 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
    #7 0x4ff9b5 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
    #8 0x4eed1f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
    #9 0x4ef5e8 in LLVMFuzzerRunDriver /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:925:10
    #10 0x4df105 in main (/build/fuzz-calendarspec+0x4df105)
    #11 0x7fb3528e3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #12 0x41f80d in _start (/build/fuzz-calendarspec+0x41f80d)

Found by Nallocfuzz.
yuwata pushed a commit that referenced this pull request May 21, 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.
yuwata pushed a commit that referenced this pull request May 22, 2023
==8==ERROR: LeakSanitizer: detected memory leaks

Indirect leak of 168 byte(s) in 3 object(s) allocated from:
    #0 0x4a0e6e in __interceptor_calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:77:3
    #1 0x4dec61 in calloc (/build/fuzz-bus-match+0x4dec61)
    #2 0x7f7c25e2b92d in bus_match_add_leaf /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-match.c:548:13
    #3 0x7f7c25e2b92d in bus_match_add /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-match.c:886:16
    #4 0x4de864 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/libsystemd/sd-bus/fuzz-bus-match.c:83:21
    #5 0x4defc8 in NaloFuzzerTestOneInput (/build/fuzz-bus-match+0x4defc8)
    #6 0x4fdf53 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
    #7 0x4fd73a 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 0x4fee09 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
    #9 0x4ffad5 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 0x4eee3f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
    #11 0x4ef708 in LLVMFuzzerRunDriver /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:925:10
    #12 0x4df225 in main (/build/fuzz-bus-match+0x4df225)
    #13 0x7f7c252e3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)

DEDUP_TOKEN: __interceptor_calloc--calloc--bus_match_add_leaf
SUMMARY: AddressSanitizer: 168 byte(s) leaked in 3 allocation(s).

Found by Nallocfuzz.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants