Skip to content

Conversation

@poettering poettering force-pushed the homed branch 3 times, most recently from bf96976 to c809ed7 Compare January 28, 2020 21:43
@j1mc j1mc closed this Jan 31, 2020
@j1mc j1mc deleted the homed-docs-patch branch January 31, 2020 15:39
poettering pushed a commit that referenced this pull request May 6, 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
    systemd#4 0x51fd16 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:556:15
    systemd#5 0x51c330 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:470:3
    systemd#6 0x523700 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:765:7
    systemd#7 0x5246cd in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:792:3
    systemd#8 0x4de3d1 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:824:6
    systemd#9 0x4cfb47 in main /src/libfuzzer/FuzzerMain.cpp:19:10
    systemd#10 0x7f864e69782f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    systemd#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
poettering pushed a commit that referenced this pull request May 18, 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
    systemd#4 0x401570 in LLVMFuzzerTestOneInput ../src/fuzz/fuzz-calendarspec.c:17
    systemd#5 0x401ae0 in main ../src/fuzz/fuzz-main.c:39
    systemd#6 0x7f0b9e31b1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
    systemd#7 0x40122d in _start (/home/fsumsal/repos/systemd/build/fuzz-calendarspec+0x40122d)

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/shared/calendarspec.c:666:48 in
```
poettering pushed a commit that referenced this pull request May 22, 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)
    systemd#4 0x7faf3d6d7b1f  (/lib64/libpthread.so.0+0x14b1f)
    systemd#5 0x7faf3d3c2624 in raise (/lib64/libc.so.6+0x3c624)
    systemd#6 0x7faf3d3ab8d8 in abort (/lib64/libc.so.6+0x258d8)
    systemd#7 0x7faf3e12593a in log_assert_failed_realm /home/vagrant/systemd/build/../src/basic/log.c:819:9
    systemd#8 0x7faf3e140ce1 in safe_atou8 /home/vagrant/systemd/build/../src/basic/parse-util.c:458:9
    systemd#9 0x68089c in config_parse_dhcp_send_option /home/vagrant/systemd/build/../src/network/networkd-dhcp-common.c:517:21
    systemd#10 0x7faf3debed4e in next_assignment /home/vagrant/systemd/build/../src/shared/conf-parser.c:132:32
    systemd#11 0x7faf3deb7783 in parse_line /home/vagrant/systemd/build/../src/shared/conf-parser.c:270:16
    systemd#12 0x7faf3deb606c in config_parse /home/vagrant/systemd/build/../src/shared/conf-parser.c:395:21
    systemd#13 0x7faf3deb85ee in config_parse_many_files /home/vagrant/systemd/build/../src/shared/conf-parser.c:452:21
    systemd#14 0x7faf3deb8c57 in config_parse_many /home/vagrant/systemd/build/../src/shared/conf-parser.c:511:16
    systemd#15 0x57c2eb in network_load_one /home/vagrant/systemd/build/../src/network/networkd-network.c:470:13
    systemd#16 0x543490 in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/network/fuzz-network-parser.c:26:16
    systemd#17 0x44e3e8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x44e3e8)
    systemd#18 0x433505 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x433505)
    systemd#19 0x43c449 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/out/fuzz-network-parser+0x43c449)
    systemd#20 0x42c4a6 in main (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4a6)
    systemd#21 0x7faf3d3ad1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
    systemd#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

```
poettering 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
    systemd#4 0x7f6ff0641dde in sd_bus_message_enter_container /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:4136:21
    systemd#5 0x7f6ff0619874 in sd_bus_message_dump /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-dump.c:178:29
    systemd#6 0x4293d9 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-bus-message.c:39:9
    systemd#7 0x441986 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:558:15
    systemd#8 0x44121e in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:470:3
    systemd#9 0x443164 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:770:7
    systemd#10 0x4434bc in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:799:3
    systemd#11 0x42d2bc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:846:6
    systemd#12 0x42978a in main /src/libfuzzer/FuzzerMain.cpp:19:10
    systemd#13 0x7f6fef13c82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    systemd#14 0x407808 in _start (out/fuzz-bus-message+0x407808)
poettering pushed a commit that referenced this pull request Jun 24, 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
    systemd#4 0x7f0a52b2f74e in next_assignment /work/build/../../src/systemd/src/shared/conf-parser.c:133:32
    systemd#5 0x7f0a52b2954e in parse_line /work/build/../../src/systemd/src/shared/conf-parser.c:242:16
    systemd#6 0x7f0a52b28911 in config_parse /work/build/../../src/systemd/src/shared/conf-parser.c:377:21
    systemd#7 0x7f0a52b29ec6 in config_parse_many_files /work/build/../../src/systemd/src/shared/conf-parser.c:439:21
    systemd#8 0x7f0a52b2a5a6 in config_parse_many /work/build/../../src/systemd/src/shared/conf-parser.c:507:16
    systemd#9 0x4d8d6c in netdev_load_one /work/build/../../src/systemd/src/network/netdev/netdev.c:732:13
    systemd#10 0x4d3e2b in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/network/fuzz-netdev-parser.c:23:16
    systemd#11 0x6b3266 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:558:15
    systemd#12 0x6af860 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:470:3
    systemd#13 0x6b6970 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:770:7
    systemd#14 0x6b7376 in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:799:3
    systemd#15 0x67573f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:846:6
    systemd#16 0x667097 in main /src/libfuzzer/FuzzerMain.cpp:19:10
    systemd#17 0x7f0a5189e82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    systemd#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
poettering pushed a commit that referenced this pull request Sep 18, 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]:     systemd#4 0x559cd058c101 in run /systemd-meson-build/../build/src/home/homectl.c:3325:16
testsuite-46.sh[74]:     systemd#5 0x559cd058c00a in main /systemd-meson-build/../build/src/home/homectl.c:3328:1
testsuite-46.sh[74]:     systemd#6 0x7f3e9a88b151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
testsuite-46.sh[74]:     systemd#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?
poettering pushed a commit that referenced this pull request Mar 8, 2021
C.f. 9793530.

We'd crash when trying to access an already-deallocated object:

Thread no. 1 (7 frames)
 #2 log_assert_failed_realm at ../src/basic/log.c:844
 #3 event_inotify_data_drop at ../src/libsystemd/sd-event/sd-event.c:3035
 systemd#4 source_dispatch at ../src/libsystemd/sd-event/sd-event.c:3250
 systemd#5 sd_event_dispatch at ../src/libsystemd/sd-event/sd-event.c:3631
 systemd#6 sd_event_run at ../src/libsystemd/sd-event/sd-event.c:3689
 systemd#7 sd_event_loop at ../src/libsystemd/sd-event/sd-event.c:3711
 systemd#8 run at ../src/home/homed.c:47

The source in question is an inotify source, and the messages are:

systemd-homed[1340]: /home/ moved or renamed, recreating watch and rescanning.
systemd-homed[1340]: Assertion '*_head == _item' failed at src/libsystemd/sd-event/sd-event.c:3035, function event_inotify_data_drop(). Aborting.

on_home_inotify() got called, then manager_watch_home(), which unrefs the
existing inotify_event_source. I assume that the source gets dispatched again
because it was still in the pending queue.

I can't reproduce the issue (timing?), but this should
fix systemd#17824, https://bugzilla.redhat.com/show_bug.cgi?id=1899264.
poettering pushed a commit that referenced this pull request Mar 23, 2021
When trying to calculate the next firing of 'Sun *-*-* 01:00:00', we'd fall
into an infinite loop, because mktime() moves us "backwards":

Before this patch:
tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00
tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00
tm_within_bounds: good=0 2021-03-29 01:00:00 → 2021-03-29 00:00:00
...

We rely on mktime() normalizing the time. The man page does not say that it'll
move the time forward, but our algorithm relies on this. So let's catch this
case explicitly.

With this patch:
$ TZ=Europe/Dublin faketime 2021-03-21 build/systemd-analyze calendar --iterations=5 'Sun *-*-* 01:00:00'
Normalized form: Sun *-*-* 01:00:00
    Next elapse: Sun 2021-03-21 01:00:00 GMT
       (in UTC): Sun 2021-03-21 01:00:00 UTC
       From now: 59min left
       Iter. #2: Sun 2021-04-04 01:00:00 IST
       (in UTC): Sun 2021-04-04 00:00:00 UTC
       From now: 1 weeks 6 days left           <---- note the 2 week jump here
       Iter. #3: Sun 2021-04-11 01:00:00 IST
       (in UTC): Sun 2021-04-11 00:00:00 UTC
       From now: 2 weeks 6 days left
       Iter. systemd#4: Sun 2021-04-18 01:00:00 IST
       (in UTC): Sun 2021-04-18 00:00:00 UTC
       From now: 3 weeks 6 days left
       Iter. systemd#5: Sun 2021-04-25 01:00:00 IST
       (in UTC): Sun 2021-04-25 00:00:00 UTC
       From now: 1 months 4 days left

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1941335.
poettering pushed a commit that referenced this pull request Jun 24, 2021
Due to a little misunderstanding the last patch doesn't work as
expected, since test_create_image() is called only for the first image
(usually TEST-01-BASIC), and all subsequent images are then (possibly)
modified with test_append_files().

Follow-up to 179ca4d.
poettering pushed a commit that referenced this pull request Jan 31, 2022
It was reported as used by the linker:

> [It is] called in the setup of ld-linux-x86-64.so.2 from _dl_sysdep_start.
> My local call stack (with LTO):
>
> #0 init_cpu_features.constprop.0 (/usr/lib64/ld-linux-x86-64.so.2)
> #1 _dl_sysdep_start (/usr/lib64/ld-linux-x86-64.so.2)
> #2 _dl_start (/usr/lib64/ld-linux-x86-64.so.2)
> #3 _start (/usr/lib64/ld-linux-x86-64.so.2)
>
> Looking through the source, I think it's this (links for glibc 2.34):
> - First dl_platform_init calls _dl_x86_init_cpu_features, a wrapper for init_cpu_features.
> - Then init_cpu_features calls get_cet_status.
> - At last, get_cet_status invokes arch_prctl.

Fixes systemd#22033.
poettering pushed a commit that referenced this pull request Jan 31, 2022
by always calling journal_remote_server_destroy, which resets global
variables like journal_remote_server_global. It should prevent crashes like
```
Assertion 'journal_remote_server_global == NULL' failed at src/journal-remote/journal-remote.c:312, function int journal_remote_server_init(RemoteServer *, const char *, JournalWriteSplitMode, _Bool, _Bool)(). Aborting.
AddressSanitizer:DEADLYSIGNAL
=================================================================
==24769==ERROR: AddressSanitizer: ABRT on unknown address 0x0539000060c1 (pc 0x7f23b4d5818b bp 0x7ffcbc4080c0 sp 0x7ffcbc407e70 T0)
SCARINESS: 10 (signal)
    #0 0x7f23b4d5818b in raise /build/glibc-eX1tMB/glibc-2.31/sysdeps/unix/sysv/linux/raise.c:51:1
    #1 0x7f23b4d37858 in abort /build/glibc-eX1tMB/glibc-2.31/stdlib/abort.c:79:7
    #2 0x7f23b5731809 in log_assert_failed systemd/src/basic/log.c:866:9
```
poettering pushed a commit that referenced this pull request Jun 6, 2023
When the header= option comes before any other type= defining one, we
trip over an assertion:

Jun 04 15:45:33 H testsuite-24.sh[752]: + systemctl start [email protected]
Jun 04 15:45:33 H systemd[1]: Starting [email protected]...
Jun 04 15:45:33 H systemd-cryptsetup[4641]: Assertion 'name' failed at src/basic/strv.c:21, function strv_find(). Aborting.
...
Jun 04 15:45:33 H systemd-coredump[4643]: Process 4641 (systemd-cryptse) of user 0 dumped core.
...
                                          Stack trace of thread 4641:
                                          #0  0x00007ff9256afe5c __pthread_kill_implementation (libc.so.6 + 0x8ce5c)
                                          #1  0x00007ff92565fa76 raise (libc.so.6 + 0x3ca76)
                                          #2  0x00007ff9256497fc abort (libc.so.6 + 0x267fc)
                                          #3  0x00007ff926076047 log_assert_failed (libsystemd-shared-253.so + 0x276047)
                                          systemd#4  0x00007ff9260ab317 strv_find (libsystemd-shared-253.so + 0x2ab317)
                                          systemd#5  0x0000000000405927 parse_one_option (systemd-cryptsetup + 0x5927)
                                          systemd#6  0x0000000000407793 parse_options (systemd-cryptsetup + 0x7793)
                                          systemd#7  0x000000000040fa0c run (systemd-cryptsetup + 0xfa0c)
                                          systemd#8  0x000000000041137f main (systemd-cryptsetup + 0x1137f)
                                          systemd#9  0x00007ff92564a510 __libc_start_call_main (libc.so.6 + 0x27510)
                                          systemd#10 0x00007ff92564a5c9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x275c9)
                                          systemd#11 0x0000000000403915 _start (systemd-cryptsetup + 0x3915)
                                          ELF object binary architecture: AMD x86-64
poettering pushed a commit that referenced this pull request Jun 26, 2023
Provides coverage for systemd#26872.

With systemd#26875 reverted:

[16444.287652] testsuite-03.sh[71]: + for i in {0..19}
[16444.287652] testsuite-03.sh[71]: + systemctl start transaction-cycle0.service
[16444.359503] systemd[1]: =================================================================
[16444.360321] systemd[1]: ==1==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6180002e578e at pc 0x7f73b25ec7a6 bp 0x7ffc5531c6f0 sp 0x7ffc5531be68
[16444.360798] systemd[1]:
[16444.361044] systemd[1]: READ of size 783 at 0x6180002e578e thread T0 (systemd)
[16444.391684] systemd[1]:     #0 0x7f73b25ec7a5  (/lib64/libasan.so.5+0x557a5)
[16444.392167] systemd[1]:     #1 0x7f73b260a1d5 in __interceptor_vasprintf (/lib64/libasan.so.5+0x731d5)
[16444.392442] systemd[1]:     #2 0x7f73afa1d1e1 in log_format_iovec ../src/basic/log.c:996
[16444.392750] systemd[1]:     #3 0x7f73afa1e7b6 in log_struct_internal ../src/basic/log.c:1058
[16444.393101] systemd[1]:     systemd#4 0x7f73b1979136 in transaction_verify_order_one ../src/core/transaction.c:392
[16444.393540] systemd[1]:     systemd#5 0x7f73b197ac82 in transaction_verify_order_one ../src/core/transaction.c:463
[16444.393946] systemd[1]:     systemd#6 0x7f73b197ac82 in transaction_verify_order_one ../src/core/transaction.c:463
[16444.394262] systemd[1]:     systemd#7 0x7f73b197ac82 in transaction_verify_order_one ../src/core/transaction.c:463
[16444.394532] systemd[1]:     systemd#8 0x7f73b197ac82 in transaction_verify_order_one ../src/core/transaction.c:463
[16444.394812] systemd[1]:     systemd#9 0x7f73b197ac82 in transaction_verify_order_one ../src/core/transaction.c:463
...
poettering pushed a commit that referenced this pull request Jun 28, 2023
So we're able to detect memory leaks in our NSS modules.

An example after introducing a memory leak in nss-myhostname.c:

testsuite-71.sh[2881]: =================================================================
testsuite-71.sh[2881]: ==2880==ERROR: LeakSanitizer: detected memory leaks
testsuite-71.sh[2881]: Direct leak of 2 byte(s) in 1 object(s) allocated from:
testsuite-71.sh[2881]:     #0 0x7fa28907243b in strdup (/usr/lib64/libasan.so.8.0.0+0x7243b)
testsuite-71.sh[2881]:     #1 0x7fa286a7bc10 in gethostname_full ../src/basic/hostname-util.c:67
testsuite-71.sh[2881]:     #2 0x7fa286a74af9 in gethostname_malloc ../src/basic/hostname-util.h:24
testsuite-71.sh[2881]:     #3 0x7fa286a756f4 in _nss_myhostname_gethostbyname4_r ../src/nss-myhostname/nss-myhostname.c:79
testsuite-71.sh[2881]:     systemd#4 0x7fa288f17588 in getaddrinfo (/lib64/libc.so.6+0xf4588)
testsuite-71.sh[2881]:     systemd#5 0x7fa2890a4d93 in __interceptor_getaddrinfo.part.0 (/usr/lib64/libasan.so.8.0.0+0xa4d93)
testsuite-71.sh[2881]:     systemd#6 0x55a54b2b7159 in ahosts_keys_int.part.0 (/usr/bin/getent.orig+0x4159)
testsuite-71.sh[2881]: SUMMARY: AddressSanitizer: 2 byte(s) leaked in 1 allocation(s).
poettering pushed a commit that referenced this pull request Aug 7, 2023
Spotted while fuzzing systemd#27890.

=================================================================
==908098==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 64 byte(s) in 1 object(s) allocated from:
    #0 0x7f4efe6d81f5 in __interceptor_realloc.part.0 (/lib64/libasan.so.8+0xd81f5) (BuildId: dc689b05ca2577037af24700212bb5cce1f91c8a)
    #1 0x7f4efb8e3ace in greedy_realloc ../src/basic/alloc-util.c:70
    #2 0x7f4efb93b713 in extract_first_word ../src/basic/extract-word.c:62
    #3 0x7f4efb970d50 in set_put_strsplit ../src/basic/hashmap.c:1902
    systemd#4 0x7f4efd76c27e in exec_context_deserialize ../src/core/execute-serialize.c:3341
    systemd#5 0x7f4efd778dcb in exec_deserialize ../src/core/execute-serialize.c:4122
    systemd#6 0x4032c0 in LLVMFuzzerTestOneInput ../src/core/fuzz-execute-serialize.c:60
    systemd#7 0x403c58 in main ../src/fuzz/fuzz-main.c:50
    systemd#8 0x7f4efecccb49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
    systemd#9 0x7f4efecccc0a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
    systemd#10 0x402344 in _start (/home/mrc0mmand/repos/@systemd/systemd/build-san/fuzz-execute-serialize+0x402344) (BuildId: 195f382cf1e39b9ba48d6dcf5a90f786d72837a8)

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

==911550==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 17 byte(s) in 1 object(s) allocated from:
    #0 0x4df281 in strdup (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x4df281) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
    #1 0x7fe4ae2b38fc in _set_put_strndup_full /home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/../src/basic/hashmap.c:1868:21
    #2 0x7fe4b0bad897 in exec_context_deserialize /home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/../src/core/execute-serialize.c:3914:29
    #3 0x7fe4b0b80592 in exec_deserialize /home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/../src/core/execute-serialize.c:4109:13
    systemd#4 0x531d0f in LLVMFuzzerTestOneInput /home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/../src/core/fuzz-execute-serialize.c:59:16
    systemd#5 0x440594 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x440594) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
    systemd#6 0x43f9b9 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x43f9b9) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
    systemd#7 0x440fd5 in fuzzer::Fuzzer::MutateAndTestOne() (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x440fd5) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
    systemd#8 0x441955 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, std::allocator<fuzzer::SizedFile>>&) (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x441955) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
    systemd#9 0x42e151 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x42e151) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
    systemd#10 0x45a916 in main (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x45a916) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
    systemd#11 0x7fe4ac449b49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
    systemd#12 0x7fe4ac449c0a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
    systemd#13 0x422b74 in _start (/home/mrc0mmand/repos/@systemd/systemd/build-libfuzz/fuzz-execute-serialize+0x422b74) (BuildId: 4e58706e607b8be7972d83c421bc0b625d509ec6)
SUMMARY: AddressSanitizer: 17 byte(s) leaked in 1 allocation(s).
poettering pushed a commit that referenced this pull request Aug 22, 2023
Introduced by 41712cd.

=================================================================
==2194==ERROR: LeakSanitizer: detected memory leaks
Indirect leak of 359856 byte(s) in 459 object(s) allocated from:
    #0 0x7ffff7511df4  (/usr/lib64/clang/16/lib/linux/libclang_rt.asan-powerpc64le.so+0x191df4) (BuildId: 47e1dd371a2b8525b6cb737760a4dc535f30ea10)
    #1 0x7ffff6bb5fb0 in message_from_header /systemd-meson-build/../root/systemd/src/libsystemd/sd-bus/bus-message.c:372:13
    #2 0x7ffff6bb5fb0 in bus_message_from_malloc /systemd-meson-build/../root/systemd/src/libsystemd/sd-bus/bus-message.c:421:13
    #3 0x7ffff6c23f54 in bus_socket_make_message /systemd-meson-build/../root/systemd/src/libsystemd/sd-bus/bus-socket.c:1222:13
    systemd#4 0x7ffff6c22d10 in bus_socket_read_message /systemd-meson-build/../root/systemd/src/libsystemd/sd-bus/bus-socket.c
    systemd#5 0x7ffff6c4d414 in bus_read_message /systemd-meson-build/../root/systemd/src/libsystemd/sd-bus/sd-bus.c:2082:16
    systemd#6 0x7ffff6c4d414 in sd_bus_call /systemd-meson-build/../root/systemd/src/libsystemd/sd-bus/sd-bus.c:2480:21
    systemd#7 0x7ffff6682904 in bus_service_manager_reload /systemd-meson-build/../root/systemd/src/shared/bus-unit-util.c:2823:13
    systemd#8 0x1000d570 in daemon_reload /systemd-meson-build/../root/systemd/src/sysext/sysext.c:233:16
    systemd#9 0x100090f8 in merge /systemd-meson-build/../root/systemd/src/sysext/sysext.c:895:21
    systemd#10 0x10006ff4 in verb_merge /systemd-meson-build/../root/systemd/src/sysext/sysext.c:964:16
    systemd#11 0x7ffff69ae894 in dispatch_verb /systemd-meson-build/../root/systemd/src/shared/verbs.c:103:24
    systemd#12 0x10004570 in sysext_main /systemd-meson-build/../root/systemd/src/sysext/sysext.c:1194:16
    systemd#13 0x10004570 in run /systemd-meson-build/../root/systemd/src/sysext/sysext.c:1214:16
    systemd#14 0x10004570 in main /systemd-meson-build/../root/systemd/src/sysext/sysext.c:1217:1
    systemd#15 0x7ffff5f5a968 in generic_start_main.isra.0 (/lib64/libc.so.6+0x2a968) (BuildId: c218e04818632a05c23f6fdcca16f93e95ea7de2)
    systemd#16 0x7ffff5f5ab00 in __libc_start_main (/lib64/libc.so.6+0x2ab00) (BuildId: c218e04818632a05c23f6fdcca16f93e95ea7de2)
Indirect leak of 124984 byte(s) in 459 object(s) allocated from:
...
    systemd#11 0x7ffff5f5a968 in generic_start_main.isra.0 (/lib64/libc.so.6+0x2a968) (BuildId: c218e04818632a05c23f6fdcca16f93e95ea7de2)
    systemd#12 0x7ffff5f5ab00 in __libc_start_main (/lib64/libc.so.6+0x2ab00) (BuildId: c218e04818632a05c23f6fdcca16f93e95ea7de2)
SUMMARY: AddressSanitizer: 493766 byte(s) leaked in 1383 allocation(s).
poettering pushed a commit that referenced this pull request Sep 18, 2023
When exiting PID 1 we most likely don't have stdio/stdout open, so the
final LSan check would not print any actionable information and would
just crash PID 1 leading up to a kernel panic, which is a bit annoying.
Let's instead attempt to open /dev/console, and if we succeed redirect
LSan's report there.

The result is a bit messy, as it's slightly interleaved with the kernel
panic, but it's definitely better than not having the stack trace at
all:

[  OK  ] Reached target final.target.
[  OK  ] Finished systemd-poweroff.service.
[  OK  ] Reached target poweroff.target.

=================================================================
3 1m  43.251782] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
[   43.252838] CPU: 2 PID: 1 Comm: systemd Not tainted 6.4.12-200.fc38.x86_64 #1
==[1==ERR O R :4 3Le.a2k53562] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014
[   43.254683] Call Trace:
[   43.254911]  <TASK>
[   43.255107]  dump_stack_lvl+0x47/0x60
S[ a  43.n2555i05]  panic+t0x192/0x350
izer[   :43.255966 ]  do_exit+0x990/0xdb10
etec[   43.256504]  do_group_exit+0x31/0x80
[   43.256889]  __x64_sys_exit_group+0x18/0x20
[   43.257288]  do_syscall_64+0x60/0x90
o_user_mod leaks[   43.257618]  ? syscall_exit_t

+0x2b/0x40
[   43.258411]  ? do_syscall_64+0x6c/0x90
1mDirect le[   43.258755]  ak of 21 byte(s)? exc_page_fault+0x7f/0x180
[   43.259446]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
 [   43.259901] RiIP: 0033:0x7f357nb8f3ad4
 1 objec[   43.260354] Ctode: 48 89 (f7 0f 05 c3 sf3 0f 1e fa b8 3b 00 00 00) 0f 05 c3 0f 1f 4 0 00 f3 0f 1e fa 50 58 b8 e7 00 00 00 48 83 ec 08 48 63 ff 0f 051
[   43.262581] RSP: 002b:00007ffc25872440 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7
a RBX: 00007f357be9b218 RCX: 00007f357b8f3ad4m:ffd
[   43.264512] RDX: 0000000000000001 RSI: 00007f357b933b63 RDI: 0000000000000001
[   43.265355] RBP: 00007f357be9b218 R08: efffffffffffffff R09: 00007ffc258721ef
[   43.266191] R10: 000000000000003f R11: 0000000000000202 R12: 00000fe6ae9e0000
[   43.266891] R13: 00007f3574f00000 R14: 0000000000000000 R15: 0000000000000007
[   43.267517]  </TASK>

    #0 0x7f357b8814a8 in strdup (/lib64/libasan.so.8+0x814a8) (BuildId: e5f0a0d511a659fbc47bf41072869139cb2db47f)
    #1 0x7f3578d43317 in cg_path_decode_unit ../src/basic/cgroup-util.c:1132
    #2 0x7f3578d43936 in cg_path_get_unit ../src/basic/cgroup-util.c:1190
    #3 0x7f3578d440f6 in cg_pid_get_unit ../src/basic/cgroup-util.c:1234
    systemd#4 0x7f35789263d7 in bus_log_caller ../src/shared/bus-util.c:734
    systemd#5 0x7f357a9cf10a in method_reload ../src/core/dbus-manager.c:1621
    systemd#6 0x7f3578f77497 in method_callbacks_run ../src/libsystemd/sd-bus/bus-objects.c:406
    systemd#7 0x7f3578f80dd8 in object_find_and_run ../src/libsystemd/sd-bus/bus-objects.c:1319
    systemd#8 0x7f3578f82487 in bus_process_object ../src/libsystemd/sd-bus/bus-objects.c:1439
    systemd#9 0x7f3578fe41f1 in process_message ../src/libsystemd/sd-bus/sd-bus.c:3007
    systemd#10 0x7f3578fe477b in process_running ../src/libsystemd/sd-bus/sd-bus.c:3049
    systemd#11 0x7f3578fe75d1 in bus_process_internal ../src/libsystemd/sd-bus/sd-bus.c:3269
    systemd#12 0x7f3578fe776e in sd_bus_process ../src/libsystemd/sd-bus/sd-bus.c:3296
    systemd#13 0x7f3578feaedc in io_callback ../src/libsystemd/sd-bus/sd-bus.c:3638
    systemd#14 0x7f35791c2f68 in source_dispatch ../src/libsystemd/sd-event/sd-event.c:4187
    systemd#15 0x7f35791cc6f9 in sd_event_dispatch ../src/libsystemd/sd-event/sd-event.c:4808
    systemd#16 0x7f35791cd830 in sd_event_run ../src/libsystemd/sd-event/sd-event.c:4869
    systemd#17 0x7f357abcd572 in manager_loop ../src/core/manager.c:3244
    systemd#18 0x41db21 in invoke_main_loop ../src/core/main.c:1960
    systemd#19 0x426615 in main ../src/core/main.c:3125
    systemd#20 0x7f3577c49b49 in __libc_start_call_main (/lib64/libc.so.6+0x27b49) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
    systemd#21 0x7f3577c49c0a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c0a) (BuildId: 245240a31888ad5c11bbc55b18e02d87388f59a9)
    systemd#22 0x408494 in _start (/usr/lib/systemd/systemd+0x408494) (BuildId: fe61e1b0f00b6a36aa34e707a98c15c52f6b960a)

SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s).
[   43.295912] Kernel Offset: 0x7000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[   43.297036] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 ]---

Originally noticed in systemd#28579.
YHNdnzj pushed a commit that referenced this pull request Nov 28, 2023
fuzzers randomly fail with the following:
```
==172==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f41169cb39b in update_argv /work/build/../../src/systemd/src/basic/argv-util.c:96:13
    #1 0x7f41169cb39b in rename_process /work/build/../../src/systemd/src/basic/argv-util.c:210:16
    #2 0x7f4116b6824e in safe_fork_full /work/build/../../src/systemd/src/basic/process-util.c:1516:21
    #3 0x7f4116bffa36 in safe_fork /work/build/../../src/systemd/src/basic/process-util.h:191:16
    systemd#4 0x7f4116bffa36 in parse_timestamp /work/build/../../src/systemd/src/basic/time-util.c:1047:13
    systemd#5 0x4a61e6 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-time-util.c:16:16
    systemd#6 0x4c4a13 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
    systemd#7 0x4c41fa in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
    systemd#8 0x4c58c9 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
    systemd#9 0x4c6595 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
    systemd#10 0x4b58ff in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
    systemd#11 0x4def52 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    systemd#12 0x7f4115ea3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: e678fe54a5d2c2092f8e47eb0b33105e380f7340)
    systemd#13 0x41f5ad in _start (build-out/fuzz-time-util+0x41f5ad)

DEDUP_TOKEN: update_argv--rename_process--safe_fork_full
  Uninitialized value was created by an allocation of 'fv' in the stack frame of function 'have_effective_cap'
    #0 0x7f41169d3540 in have_effective_cap /work/build/../../src/systemd/src/basic/capability-util.c:21
```
poettering pushed a commit that referenced this pull request Dec 12, 2023
By making assert_return() critical, we observe the following:
---
 Program received signal SIGABRT, Aborted.
 0x00007f01320b0884 in __pthread_kill_implementation () from /lib64/libc.so.6
 (gdb) bt
 #0  0x00007f01320b0884 in __pthread_kill_implementation ()
    from /lib64/libc.so.6
 #1  0x00007f013205fafe in raise () from /lib64/libc.so.6
 #2  0x00007f013204887f in abort () from /lib64/libc.so.6
 #3  0x00007f01338d02d6 in log_assert_failed (
     text=0x7f01340009e0 "e->state != SD_EVENT_FINISHED",
     file=0x7f0133fff403 "src/libsystemd/sd-event/sd-event.c", line=1399,
     func=0x7f01340045a0 <__func__.148> "sd_event_add_time")
     at ../src/basic/log.c:948
 systemd#4  0x00007f01338d0457 in log_assert_failed_return (
     text=0x7f01340009e0 "e->state != SD_EVENT_FINISHED",
     file=0x7f0133fff403 "src/libsystemd/sd-event/sd-event.c", line=1399,
     func=0x7f01340045a0 <__func__.148> "sd_event_add_time")
     at ../src/basic/log.c:967
 systemd#5  0x00007f0133c7ed83 in sd_event_add_time (e=0x617000022280,
     ret=0x610000007e98, clock=7, usec=24054941030, accuracy=0,
     callback=0x4625b4 <on_announcement_timeout>, userdata=0x610000007e40)
     at ../src/libsystemd/sd-event/sd-event.c:1399
 systemd#6  0x00007f0133c7f725 in sd_event_add_time_relative (e=0x617000022280,
     ret=0x610000007e98, clock=7, usec=1000000, accuracy=0,
     callback=0x4625b4 <on_announcement_timeout>, userdata=0x610000007e40)
     at ../src/libsystemd/sd-event/sd-event.c:1462
 systemd#7  0x0000000000464cac in dns_scope_announce (scope=0x610000007e40, goodbye=true) at ../src/resolve/resolved-dns-scope.c:1530
 systemd#8  0x0000000000504d08 in link_free (l=0x612000023d40) at ../src/resolve/resolved-link.c:83
 systemd#9  0x000000000052dbbd in manager_free (m=0x619000000a80) at ../src/resolve/resolved-manager.c:697
 systemd#10 0x0000000000562328 in manager_freep (p=0x7f012f800040) at ../src/resolve/resolved-manager.h:198
 systemd#11 0x000000000056315a in run (argc=1, argv=0x7fff22b06468) at ../src/resolve/resolved.c:25
 systemd#12 0x0000000000563284 in main (argc=1, argv=0x7fff22b06468) at ../src/resolve/resolved.c:99
---
Prompted by systemd#30049 (comment).
poettering pushed a commit that referenced this pull request Dec 12, 2023
When assert_return() is critical, the following assertion is triggered
on exit:
---
 #0  0x00007f8b1f6b0884 in __pthread_kill_implementation () from target:/lib64/libc.so.6
 #1  0x00007f8b1f65fafe in raise () from target:/lib64/libc.so.6
 #2  0x00007f8b1f64887f in abort () from target:/lib64/libc.so.6
 #3  0x00007f8b208d02d6 in log_assert_failed (text=0x7f8b210009e0 "e->state != SD_EVENT_FINISHED", file=0x7f8b20fff403 "src/libsystemd/sd-event/sd-event.c",
     line=1252, func=0x7f8b21004400 <__func__.154> "sd_event_add_io") at ../src/basic/log.c:948
 systemd#4  0x00007f8b208d0457 in log_assert_failed_return (text=0x7f8b210009e0 "e->state != SD_EVENT_FINISHED",
     file=0x7f8b20fff403 "src/libsystemd/sd-event/sd-event.c", line=1252, func=0x7f8b21004400 <__func__.154> "sd_event_add_io") at ../src/basic/log.c:967
 systemd#5  0x00007f8b20c7d102 in sd_event_add_io (e=0x617000000080, ret=0x60c000000a20, fd=11, events=1, callback=0x7dfd85 <ipv4acd_on_packet>,
     userdata=0x60c000000a00) at ../src/libsystemd/sd-event/sd-event.c:1252
 systemd#6  0x00000000007e3934 in sd_ipv4acd_start (acd=0x60c000000a00, reset_conflicts=true) at ../src/libsystemd-network/sd-ipv4acd.c:597
 systemd#7  0x00000000007e72b9 in ipv4ll_start_internal (ll=0x6080000006a0, reset_generation=true) at ../src/libsystemd-network/sd-ipv4ll.c:278
 systemd#8  0x00000000007e7462 in sd_ipv4ll_start (ll=0x6080000006a0) at ../src/libsystemd-network/sd-ipv4ll.c:298
 systemd#9  0x00000000006047a1 in dhcp4_handler (client=0x617000000400, event=0, userdata=0x61a000000680) at ../src/network/networkd-dhcp4.c:1183
 systemd#10 0x000000000075b1ed in client_notify (client=0x617000000400, event=0) at ../src/libsystemd-network/sd-dhcp-client.c:783
 systemd#11 0x000000000075bf8d in client_stop (client=0x617000000400, error=0) at ../src/libsystemd-network/sd-dhcp-client.c:821
 systemd#12 0x000000000077710f in sd_dhcp_client_stop (client=0x617000000400) at ../src/libsystemd-network/sd-dhcp-client.c:2388
 systemd#13 0x000000000065cdd1 in link_stop_engines (link=0x61a000000680, may_keep_dhcp=true) at ../src/network/networkd-link.c:336
 systemd#14 0x000000000041f214 in manager_free (m=0x618000000080) at ../src/network/networkd-manager.c:613
 systemd#15 0x00000000004124e3 in manager_freep (p=0x7f8b1c800040) at ../src/network/networkd-manager.h:128
 systemd#16 0x00000000004139f6 in run (argc=1, argv=0x7ffffe4522e8) at ../src/network/networkd.c:24
 systemd#17 0x0000000000413b20 in main (argc=1, argv=0x7ffffe4522e8) at ../src/network/networkd.c:119
---
Prompted by systemd#30049 (comment).
poettering pushed a commit that referenced this pull request Jan 2, 2024
Avoid passing a NULL message to sd_bus_message_is_signal(), to not trip
over an assertion:

[  132.869436] H testsuite-82.sh[614]: + systemctl --no-block --check-inhibitors=yes soft-reboot
[  132.967386] H systemd[1]: Created slice system-systemd\x2dcoredump.slice.
[  133.018292] H systemd[1]: Starting inhibit.service...
[  133.122610] H systemd[1]: Started [email protected].
[  133.163643] H systemd[1]: Started inhibit.service.
[  133.206836] H testsuite-82.sh[614]: + exec sleep infinity
[  133.236762] H systemd-logind[611]: The system will reboot now!
[  135.891607] H systemd-coredump[667]: [🡕] Process 663 (busctl) of user 0 dumped core.

                                        Stack trace of thread 663:
                                        #0  0x00007f2ec45e6acf raise (libc.so.6 + 0x4eacf)
                                        #1  0x00007f2ec45b9ea5 abort (libc.so.6 + 0x21ea5)
                                        #2  0x00007f2ec4b5c9a6 log_assert_failed (libsystemd-shared-255.so + 0x1ff9a6)
                                        #3  0x00007f2ec4b5dca5 log_assert_failed_return (libsystemd-shared-255.so + 0x200ca5)
                                        systemd#4  0x00007f2ec4bb3df6 sd_bus_message_is_signal (libsystemd-shared-255.so + 0x256df6)
                                        systemd#5  0x000000000040e478 monitor (busctl + 0xe478)
                                        systemd#6  0x000000000040e82f verb_monitor (busctl + 0xe82f)
                                        systemd#7  0x00007f2ec4b202cb dispatch_verb (libsystemd-shared-255.so + 0x1c32cb)
                                        systemd#8  0x00000000004074fa busctl_main (busctl + 0x74fa)
                                        systemd#9  0x0000000000407525 run (busctl + 0x7525)
                                        systemd#10 0x000000000040ff67 main (busctl + 0xff67)
                                        systemd#11 0x00007f2ec45d2d85 __libc_start_main (libc.so.6 + 0x3ad85)
                                        systemd#12 0x00000000004044be _start (busctl + 0x44be)
                                        ELF object binary architecture: AMD x86-64
[  136.141152] H dbus-daemon[634]: [system] Monitoring connection :1.2 closed.
[  136.152233] H systemd[1]: busctl.service: Main process exited, code=dumped, status=6/ABRT
[  136.153996] H systemd[1]: busctl.service: Failed with result 'core-dump'.

The asertion in question:

Assertion 'm' failed at src/libsystemd/sd-bus/bus-message.c:1015, function sd_bus_message_is_signal(). Aborting.

We can get a NULL message here through sd_bus_process() ->
bus_process_internal() -> process_running(), so let's handle this case
appropriately.
poettering pushed a commit that referenced this pull request Jan 2, 2024
Since in that case the event loop is already finished and we'd hit an
assertion:

[ 1295.993300] testsuite-75.sh[50]: + systemctl stop systemd-resolved.service
[ 1296.005152] systemd-resolved[298]: Assertion 'e->state != SD_EVENT_FINISHED' failed at src/libsystemd/sd-event/sd-event.c:1252, function sd_event_add_io(). Aborting.

Thread 1 (Thread 0x7f17d25e2940 (LWP 298)):
 #0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
 #1  0x00007f17d16ac8a3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
 #2  0x00007f17d165c668 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
 #3  0x00007f17d16444b8 in __GI_abort () at abort.c:79
 systemd#4  0x00007f17d2402d2d in log_assert_failed (text=<optimized out>, file=<optimized out>, line=<optimized out>, func=<optimized out>) at ../build/src/basic/log.c:968
 systemd#5  0x00007f17d240401c in log_assert_failed_return (text=text@entry=0x7f17d2533f13 "e->state != SD_EVENT_FINISHED", file=file@entry=0x7f17d25195d9 "src/libsystemd/sd-event/sd-event.c", line=line@entry=1252, func=func@entry=0x7f17d2567260 <__func__.140> "sd_event_add_io") at ../build/src/basic/log.c:987
 systemd#6  0x00007f17d24d011a in sd_event_add_io (e=0x55e5cb497270, ret=0x55e5cb4a5120, fd=fd@entry=26, events=events@entry=1, callback=callback@entry=0x55e5caff5466 <on_io_event>, userdata=0x55e5cb4a5110) at ../build/src/libsystemd/sd-event/sd-event.c:1252
 systemd#7  0x000055e5caff571c in manager_add_socket_to_graveyard (m=0x55e5cb43cf00, fd=26) at ../build/src/resolve/resolved-socket-graveyard.c:117
 systemd#8  0x000055e5cafd4253 in dns_transaction_close_connection (t=t@entry=0x55e5cb57c7d0, use_graveyard=use_graveyard@entry=true) at ../build/src/resolve/resolved-dns-transaction.c:78
 systemd#9  0x000055e5cafd8444 in dns_transaction_complete (t=t@entry=0x55e5cb57c7d0, state=state@entry=DNS_TRANSACTION_ABORTED) at ../build/src/resolve/resolved-dns-transaction.c:427
 systemd#10 0x000055e5cafc4969 in dns_scope_abort_transactions (s=s@entry=0x55e5cb4b1a70) at ../build/src/resolve/resolved-dns-scope.c:91
 systemd#11 0x000055e5cafc6aee in dns_scope_free (s=0x55e5cb4b1a70) at ../build/src/resolve/resolved-dns-scope.c:106
 systemd#12 0x000055e5cafe72d1 in link_free (l=0x55e5cb4a5160) at ../build/src/resolve/resolved-link.c:94
 systemd#13 0x000055e5cafedefc in manager_free (m=0x55e5cb43cf00) at ../build/src/resolve/resolved-manager.c:697
 systemd#14 0x000055e5caff99b6 in manager_freep (p=p@entry=0x7ffd71fab8f8) at ../build/src/resolve/resolved-manager.h:198
 systemd#15 0x000055e5caff9d66 in run (argc=argc@entry=1, argv=argv@entry=0x7ffd71faba78) at ../build/src/resolve/resolved.c:25
 systemd#16 0x000055e5caff9fe3 in main (argc=1, argv=0x7ffd71faba78) at ../build/src/resolve/resolved.c:99

Resolves: systemd#30618
poettering pushed a commit that referenced this pull request Jan 8, 2024
Since libfuzzer feeds a single fuzzing process with multiple inputs, we
might carry over arg_transport from a previous invocation, tripping over
the assert in acquire_bus():

+----------------------------------------Release Build Stacktrace----------------------------------------+
Assertion 'transport != BUS_TRANSPORT_REMOTE || runtime_scope == RUNTIME_SCOPE_SYSTEM' failed at src/shared/bus-util.c:284, function bus_connect_transport(). Aborting.
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2739==ERROR: AddressSanitizer: ABRT on unknown address 0x00000ab3 (pc 0xf7f52509 bp 0xffdf74cc sp 0xffdf74b0 T0)
SCARINESS: 10 (signal)
    #0 0xf7f52509 in linux-gate.so.1
    #1 0xf703b415 in raise
    #2 0xf70233f6 in abort
    #3 0xf772ac0a in log_assert_failed systemd/src/basic/log.c:968:9
    systemd#4 0xf77300d5 in log_assert_failed_return systemd/src/basic/log.c:987:17
    systemd#5 0xf7432bbf in bus_connect_transport systemd/src/shared/bus-util.c:284:9
    systemd#6 0x818cd17 in acquire_bus systemd/src/systemctl/systemctl-util.c:53:29
    systemd#7 0x815fd3c in help_boot_loader_entry systemd/src/systemctl/systemctl-logind.c:431:13
    systemd#8 0x819ca87 in systemctl_parse_argv systemd/src/systemctl/systemctl.c:863:37
    systemd#9 0x8197632 in systemctl_dispatch_parse_argv systemd/src/systemctl/systemctl.c:1137:16
    systemd#10 0x813328d in LLVMFuzzerTestOneInput systemd/src/systemctl/fuzz-systemctl-parse-argv.c:54:13
    systemd#11 0x81bbe7e in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned int) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
    systemd#12 0x81bb5b8 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned int, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
    systemd#13 0x81bd42d in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:826:7
    systemd#14 0x81bd62e in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:857:3
    systemd#15 0x81ac84c in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned int)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
    systemd#16 0x81d65c7 in main /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
    systemd#17 0xf7024ed4 in __libc_start_main
    systemd#18 0x806bdb5 in _start

Resolves: systemd#30802
poettering pushed a commit that referenced this pull request Jan 18, 2024
To appease gcc-14's -Wcalloc-transposed-args check.

Follow-up for 2a9ab09.
poettering added a commit that referenced this pull request Jan 18, 2024
Reorder arguments for calloc()-like functions, part #2
poettering pushed a commit that referenced this pull request Feb 23, 2024
Similarly to bbac11c we need to enable session lingering for the test
user, so the long-running test units are not killed prematurely:

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

Addresses systemd#31426 (comment).
poettering added a commit that referenced this pull request Aug 29, 2024
…ck policy

So far you had to pick:

1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor
   blesses your setup via signature)
or
2. Use a pcrlock policy (i.e. local system blesses your setup via
   dynamic local policy stored in NV index)

It was not possible combine these two, because TPM2 access policies do
not allow the combination of PolicyAuthorize (used to implement #1
above) and PolicyAuthorizeNV (used to implement #2) in a single policy,
unless one is "further upstream" (and can simply remove the other from
the policy freely).

This is quite limiting of course, since we actually do want to enforce
on each TPM object that both the OS vendor policy and the local policy
must be fulfilled, without the chance for the vendor or the local system
to disable the other.

This patch addresses this: instead of trying to find a way to come up
with some adventurous scheme to combine both policy into one TPM2
policy, we simply shard the symmetric LUKS decryption key: one half we
protect via the signed PCR policy, and the other we protect via the
pcrlock policy. Only if both halves can be acquired the disk can be
decrypted.

This means:

1. we simply double the unlock key in length in case both policies shall
   be used.
2. We store two resulting TPM policy hashes in the LUKS token JSON, one
   for each policy
3. We store two sealed TPM policy key blobs in the LUKS token JSON, for
   both halves of the LUKS unlock key.

This patch keeps the "sharding" logic relatively generic (i.e. the low
level logic is actually fine with more than 2 shards), because I figure
sooner or later we might have to encode more shards, for example if we
add further TPM2-based access policies, for example when combining FIDO2
with TPM2, or implementing TOTP for this.
poettering added a commit that referenced this pull request Aug 30, 2024
…ck policy

So far you had to pick:

1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor
   blesses your setup via signature)
or
2. Use a pcrlock policy (i.e. local system blesses your setup via
   dynamic local policy stored in NV index)

It was not possible combine these two, because TPM2 access policies do
not allow the combination of PolicyAuthorize (used to implement #1
above) and PolicyAuthorizeNV (used to implement #2) in a single policy,
unless one is "further upstream" (and can simply remove the other from
the policy freely).

This is quite limiting of course, since we actually do want to enforce
on each TPM object that both the OS vendor policy and the local policy
must be fulfilled, without the chance for the vendor or the local system
to disable the other.

This patch addresses this: instead of trying to find a way to come up
with some adventurous scheme to combine both policy into one TPM2
policy, we simply shard the symmetric LUKS decryption key: one half we
protect via the signed PCR policy, and the other we protect via the
pcrlock policy. Only if both halves can be acquired the disk can be
decrypted.

This means:

1. we simply double the unlock key in length in case both policies shall
   be used.
2. We store two resulting TPM policy hashes in the LUKS token JSON, one
   for each policy
3. We store two sealed TPM policy key blobs in the LUKS token JSON, for
   both halves of the LUKS unlock key.

This patch keeps the "sharding" logic relatively generic (i.e. the low
level logic is actually fine with more than 2 shards), because I figure
sooner or later we might have to encode more shards, for example if we
add further TPM2-based access policies, for example when combining FIDO2
with TPM2, or implementing TOTP for this.
poettering added a commit that referenced this pull request Aug 30, 2024
…ck policy

So far you had to pick:

1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor
   blesses your setup via signature)
or
2. Use a pcrlock policy (i.e. local system blesses your setup via
   dynamic local policy stored in NV index)

It was not possible combine these two, because TPM2 access policies do
not allow the combination of PolicyAuthorize (used to implement #1
above) and PolicyAuthorizeNV (used to implement #2) in a single policy,
unless one is "further upstream" (and can simply remove the other from
the policy freely).

This is quite limiting of course, since we actually do want to enforce
on each TPM object that both the OS vendor policy and the local policy
must be fulfilled, without the chance for the vendor or the local system
to disable the other.

This patch addresses this: instead of trying to find a way to come up
with some adventurous scheme to combine both policy into one TPM2
policy, we simply shard the symmetric LUKS decryption key: one half we
protect via the signed PCR policy, and the other we protect via the
pcrlock policy. Only if both halves can be acquired the disk can be
decrypted.

This means:

1. we simply double the unlock key in length in case both policies shall
   be used.
2. We store two resulting TPM policy hashes in the LUKS token JSON, one
   for each policy
3. We store two sealed TPM policy key blobs in the LUKS token JSON, for
   both halves of the LUKS unlock key.

This patch keeps the "sharding" logic relatively generic (i.e. the low
level logic is actually fine with more than 2 shards), because I figure
sooner or later we might have to encode more shards, for example if we
add further TPM2-based access policies, for example when combining FIDO2
with TPM2, or implementing TOTP for this.
poettering added a commit that referenced this pull request Aug 30, 2024
…ck policy

So far you had to pick:

1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor
   blesses your setup via signature)
or
2. Use a pcrlock policy (i.e. local system blesses your setup via
   dynamic local policy stored in NV index)

It was not possible combine these two, because TPM2 access policies do
not allow the combination of PolicyAuthorize (used to implement #1
above) and PolicyAuthorizeNV (used to implement #2) in a single policy,
unless one is "further upstream" (and can simply remove the other from
the policy freely).

This is quite limiting of course, since we actually do want to enforce
on each TPM object that both the OS vendor policy and the local policy
must be fulfilled, without the chance for the vendor or the local system
to disable the other.

This patch addresses this: instead of trying to find a way to come up
with some adventurous scheme to combine both policy into one TPM2
policy, we simply shard the symmetric LUKS decryption key: one half we
protect via the signed PCR policy, and the other we protect via the
pcrlock policy. Only if both halves can be acquired the disk can be
decrypted.

This means:

1. we simply double the unlock key in length in case both policies shall
   be used.
2. We store two resulting TPM policy hashes in the LUKS token JSON, one
   for each policy
3. We store two sealed TPM policy key blobs in the LUKS token JSON, for
   both halves of the LUKS unlock key.

This patch keeps the "sharding" logic relatively generic (i.e. the low
level logic is actually fine with more than 2 shards), because I figure
sooner or later we might have to encode more shards, for example if we
add further TPM2-based access policies, for example when combining FIDO2
with TPM2, or implementing TOTP for this.
poettering added a commit that referenced this pull request Sep 2, 2024
…ck policy

So far you had to pick:

1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor
   blesses your setup via signature)
or
2. Use a pcrlock policy (i.e. local system blesses your setup via
   dynamic local policy stored in NV index)

It was not possible combine these two, because TPM2 access policies do
not allow the combination of PolicyAuthorize (used to implement #1
above) and PolicyAuthorizeNV (used to implement #2) in a single policy,
unless one is "further upstream" (and can simply remove the other from
the policy freely).

This is quite limiting of course, since we actually do want to enforce
on each TPM object that both the OS vendor policy and the local policy
must be fulfilled, without the chance for the vendor or the local system
to disable the other.

This patch addresses this: instead of trying to find a way to come up
with some adventurous scheme to combine both policy into one TPM2
policy, we simply shard the symmetric LUKS decryption key: one half we
protect via the signed PCR policy, and the other we protect via the
pcrlock policy. Only if both halves can be acquired the disk can be
decrypted.

This means:

1. we simply double the unlock key in length in case both policies shall
   be used.
2. We store two resulting TPM policy hashes in the LUKS token JSON, one
   for each policy
3. We store two sealed TPM policy key blobs in the LUKS token JSON, for
   both halves of the LUKS unlock key.

This patch keeps the "sharding" logic relatively generic (i.e. the low
level logic is actually fine with more than 2 shards), because I figure
sooner or later we might have to encode more shards, for example if we
add further TPM2-based access policies, for example when combining FIDO2
with TPM2, or implementing TOTP for this.
poettering added a commit that referenced this pull request Sep 2, 2024
…ck policy

So far you had to pick:

1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor
   blesses your setup via signature)
or
2. Use a pcrlock policy (i.e. local system blesses your setup via
   dynamic local policy stored in NV index)

It was not possible combine these two, because TPM2 access policies do
not allow the combination of PolicyAuthorize (used to implement #1
above) and PolicyAuthorizeNV (used to implement #2) in a single policy,
unless one is "further upstream" (and can simply remove the other from
the policy freely).

This is quite limiting of course, since we actually do want to enforce
on each TPM object that both the OS vendor policy and the local policy
must be fulfilled, without the chance for the vendor or the local system
to disable the other.

This patch addresses this: instead of trying to find a way to come up
with some adventurous scheme to combine both policy into one TPM2
policy, we simply shard the symmetric LUKS decryption key: one half we
protect via the signed PCR policy, and the other we protect via the
pcrlock policy. Only if both halves can be acquired the disk can be
decrypted.

This means:

1. we simply double the unlock key in length in case both policies shall
   be used.
2. We store two resulting TPM policy hashes in the LUKS token JSON, one
   for each policy
3. We store two sealed TPM policy key blobs in the LUKS token JSON, for
   both halves of the LUKS unlock key.

This patch keeps the "sharding" logic relatively generic (i.e. the low
level logic is actually fine with more than 2 shards), because I figure
sooner or later we might have to encode more shards, for example if we
add further TPM2-based access policies, for example when combining FIDO2
with TPM2, or implementing TOTP for this.
poettering added a commit that referenced this pull request Sep 6, 2024
…ck policy

So far you had to pick:

1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor
   blesses your setup via signature)
or
2. Use a pcrlock policy (i.e. local system blesses your setup via
   dynamic local policy stored in NV index)

It was not possible combine these two, because TPM2 access policies do
not allow the combination of PolicyAuthorize (used to implement #1
above) and PolicyAuthorizeNV (used to implement #2) in a single policy,
unless one is "further upstream" (and can simply remove the other from
the policy freely).

This is quite limiting of course, since we actually do want to enforce
on each TPM object that both the OS vendor policy and the local policy
must be fulfilled, without the chance for the vendor or the local system
to disable the other.

This patch addresses this: instead of trying to find a way to come up
with some adventurous scheme to combine both policy into one TPM2
policy, we simply shard the symmetric LUKS decryption key: one half we
protect via the signed PCR policy, and the other we protect via the
pcrlock policy. Only if both halves can be acquired the disk can be
decrypted.

This means:

1. we simply double the unlock key in length in case both policies shall
   be used.
2. We store two resulting TPM policy hashes in the LUKS token JSON, one
   for each policy
3. We store two sealed TPM policy key blobs in the LUKS token JSON, for
   both halves of the LUKS unlock key.

This patch keeps the "sharding" logic relatively generic (i.e. the low
level logic is actually fine with more than 2 shards), because I figure
sooner or later we might have to encode more shards, for example if we
add further TPM2-based access policies, for example when combining FIDO2
with TPM2, or implementing TOTP for this.
poettering added a commit that referenced this pull request Sep 6, 2024
…ck policy

So far you had to pick:

1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor
   blesses your setup via signature)
or
2. Use a pcrlock policy (i.e. local system blesses your setup via
   dynamic local policy stored in NV index)

It was not possible combine these two, because TPM2 access policies do
not allow the combination of PolicyAuthorize (used to implement #1
above) and PolicyAuthorizeNV (used to implement #2) in a single policy,
unless one is "further upstream" (and can simply remove the other from
the policy freely).

This is quite limiting of course, since we actually do want to enforce
on each TPM object that both the OS vendor policy and the local policy
must be fulfilled, without the chance for the vendor or the local system
to disable the other.

This patch addresses this: instead of trying to find a way to come up
with some adventurous scheme to combine both policy into one TPM2
policy, we simply shard the symmetric LUKS decryption key: one half we
protect via the signed PCR policy, and the other we protect via the
pcrlock policy. Only if both halves can be acquired the disk can be
decrypted.

This means:

1. we simply double the unlock key in length in case both policies shall
   be used.
2. We store two resulting TPM policy hashes in the LUKS token JSON, one
   for each policy
3. We store two sealed TPM policy key blobs in the LUKS token JSON, for
   both halves of the LUKS unlock key.

This patch keeps the "sharding" logic relatively generic (i.e. the low
level logic is actually fine with more than 2 shards), because I figure
sooner or later we might have to encode more shards, for example if we
add further TPM2-based access policies, for example when combining FIDO2
with TPM2, or implementing TOTP for this.
poettering added a commit that referenced this pull request Sep 6, 2024
…ck policy

So far you had to pick:

1. Use a signed PCR TPM2 policy to lock your disk to (i.e. UKI vendor
   blesses your setup via signature)
or
2. Use a pcrlock policy (i.e. local system blesses your setup via
   dynamic local policy stored in NV index)

It was not possible combine these two, because TPM2 access policies do
not allow the combination of PolicyAuthorize (used to implement #1
above) and PolicyAuthorizeNV (used to implement #2) in a single policy,
unless one is "further upstream" (and can simply remove the other from
the policy freely).

This is quite limiting of course, since we actually do want to enforce
on each TPM object that both the OS vendor policy and the local policy
must be fulfilled, without the chance for the vendor or the local system
to disable the other.

This patch addresses this: instead of trying to find a way to come up
with some adventurous scheme to combine both policy into one TPM2
policy, we simply shard the symmetric LUKS decryption key: one half we
protect via the signed PCR policy, and the other we protect via the
pcrlock policy. Only if both halves can be acquired the disk can be
decrypted.

This means:

1. we simply double the unlock key in length in case both policies shall
   be used.
2. We store two resulting TPM policy hashes in the LUKS token JSON, one
   for each policy
3. We store two sealed TPM policy key blobs in the LUKS token JSON, for
   both halves of the LUKS unlock key.

This patch keeps the "sharding" logic relatively generic (i.e. the low
level logic is actually fine with more than 2 shards), because I figure
sooner or later we might have to encode more shards, for example if we
add further TPM2-based access policies, for example when combining FIDO2
with TPM2, or implementing TOTP for this.
poettering pushed a commit that referenced this pull request Jan 2, 2025
All other usages of sd_varlink_call* do not free the json return parameter,
and it is owned by the varlink object instead. Do the same here.

TEST-54-CREDS.sh[1074]: ==1074==ERROR: AddressSanitizer: heap-use-after-free on address 0x50c00000095a at pc 0x55cf8cd18a0f bp 0x7ffd7b9d4f10 sp 0x7ffd7b9d4f08
TEST-54-CREDS.sh[1074]: READ of size 2 at 0x50c00000095a thread T0 ((sd-mkdcreds))
TEST-54-CREDS.sh[1074]:     #0 0x55cf8cd18a0e in sd_json_variant_unref /usr/src/debug/systemd/src/libsystemd/sd-json/sd-json.c:887:16
TEST-54-CREDS.sh[1074]:     #1 0x55cf8cd4cecb in varlink_clear_current /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:593:22
TEST-54-CREDS.sh[1074]:     #2 0x55cf8cd4975e in varlink_clear /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:614:9
TEST-54-CREDS.sh[1074]:     #3 0x55cf8cd3dc3c in varlink_destroy /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:651:9
TEST-54-CREDS.sh[1074]:     systemd#4 0x55cf8cd3dc3c in sd_varlink_unref /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:657:1
TEST-54-CREDS.sh[1074]:     systemd#5 0x55cf8cb47a82 in sd_varlink_unrefp /usr/src/debug/systemd/src/systemd/sd-varlink.h:279:1
TEST-54-CREDS.sh[1074]:     systemd#6 0x55cf8cb47a82 in ipc_decrypt_credential /usr/src/debug/systemd/src/shared/creds-util.c:1660:1
TEST-54-CREDS.sh[1074]:     systemd#7 0x55cf8caca99a in maybe_decrypt_and_write_credential /usr/src/debug/systemd/src/core/exec-credential.c:486:29
TEST-54-CREDS.sh[1074]:     systemd#8 0x55cf8cac790b in load_credential /usr/src/debug/systemd/src/core/exec-credential.c:713:16
TEST-54-CREDS.sh[1074]:     systemd#9 0x55cf8cac5403 in acquire_credentials /usr/src/debug/systemd/src/core/exec-credential.c:819:29
TEST-54-CREDS.sh[1074]:     systemd#10 0x55cf8cac5403 in setup_credentials_internal /usr/src/debug/systemd/src/core/exec-credential.c:1023:13
TEST-54-CREDS.sh[1074]:     systemd#11 0x55cf8cac42d4 in exec_setup_credentials /usr/src/debug/systemd/src/core/exec-credential.c:1168:21
TEST-54-CREDS.sh[1074]:     systemd#12 0x55cf8ca59569 in exec_invoke /usr/src/debug/systemd/src/core/exec-invoke.c:4866:13
TEST-54-CREDS.sh[1074]:     systemd#13 0x55cf8ca428d8 in run /usr/src/debug/systemd/src/core/executor.c:244:13
TEST-54-CREDS.sh[1074]:     systemd#14 0x55cf8ca428d8 in main /usr/src/debug/systemd/src/core/executor.c:275:13
TEST-54-CREDS.sh[1074]:     systemd#15 0x7f64b40110c7 in __libc_start_call_main (/lib64/libc.so.6+0x40c7) (BuildId: 159846287d47eef88f2a478f59803f6e8fc81d05)
TEST-54-CREDS.sh[1074]:     systemd#16 0x7f64b401118a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x418a) (BuildId: 159846287d47eef88f2a478f59803f6e8fc81d05)
TEST-54-CREDS.sh[1074]:     systemd#17 0x55cf8ca41cb4  (/usr/lib/systemd/systemd-executor+0x124cb4) (BuildId: 24f2b1608c3aaee3226cdd14fa2b6e6741156222)
TEST-54-CREDS.sh[1074]: 0x50c00000095a is located 26 bytes inside of 120-byte region [0x50c000000940,0x50c0000009b8)
TEST-54-CREDS.sh[1074]: freed by thread T0 ((sd-mkdcreds)) here:
TEST-54-CREDS.sh[1074]:     #0 0x7f64b48d57ea in free (/usr/lib/clang/19/lib/x86_64-redhat-linux-gnu/libclang_rt.asan.so+0xd57ea) (BuildId: c59bbd28ceb74038a60373d4a8cd4c258bcf0b4e)
TEST-54-CREDS.sh[1074]:     #1 0x55cf8cd188ab in sd_json_variant_unref /usr/src/debug/systemd/src/libsystemd/sd-json/sd-json.c:895:25
TEST-54-CREDS.sh[1074]:     #2 0x55cf8cb47a4c in sd_json_variant_unrefp /usr/src/debug/systemd/src/systemd/sd-json.h:98:1
TEST-54-CREDS.sh[1074]:     #3 0x55cf8cb47a4c in ipc_decrypt_credential /usr/src/debug/systemd/src/shared/creds-util.c:1660:1
TEST-54-CREDS.sh[1074]:     systemd#4 0x55cf8caca99a in maybe_decrypt_and_write_credential /usr/src/debug/systemd/src/core/exec-credential.c:486:29
TEST-54-CREDS.sh[1074]:     systemd#5 0x55cf8cac790b in load_credential /usr/src/debug/systemd/src/core/exec-credential.c:713:16
TEST-54-CREDS.sh[1074]:     systemd#6 0x55cf8cac5403 in acquire_credentials /usr/src/debug/systemd/src/core/exec-credential.c:819:29
TEST-54-CREDS.sh[1074]:     systemd#7 0x55cf8cac5403 in setup_credentials_internal /usr/src/debug/systemd/src/core/exec-credential.c:1023:13
TEST-54-CREDS.sh[1074]:     systemd#8 0x55cf8cac42d4 in exec_setup_credentials /usr/src/debug/systemd/src/core/exec-credential.c:1168:21
TEST-54-CREDS.sh[1074]:     systemd#9 0x55cf8ca59569 in exec_invoke /usr/src/debug/systemd/src/core/exec-invoke.c:4866:13
TEST-54-CREDS.sh[1074]:     systemd#10 0x55cf8ca428d8 in run /usr/src/debug/systemd/src/core/executor.c:244:13
TEST-54-CREDS.sh[1074]:     systemd#11 0x55cf8ca428d8 in main /usr/src/debug/systemd/src/core/executor.c:275:13
TEST-54-CREDS.sh[1074]:     systemd#12 0x7f64b40110c7 in __libc_start_call_main (/lib64/libc.so.6+0x40c7) (BuildId: 159846287d47eef88f2a478f59803f6e8fc81d05)
TEST-54-CREDS.sh[1074]:     systemd#13 0x7f64b401118a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x418a) (BuildId: 159846287d47eef88f2a478f59803f6e8fc81d05)
TEST-54-CREDS.sh[1074]:     systemd#14 0x55cf8ca41cb4  (/usr/lib/systemd/systemd-executor+0x124cb4) (BuildId: 24f2b1608c3aaee3226cdd14fa2b6e6741156222)
TEST-54-CREDS.sh[1074]: previously allocated by thread T0 ((sd-mkdcreds)) here:
TEST-54-CREDS.sh[1074]:     #0 0x7f64b48d5a83 in malloc (/usr/lib/clang/19/lib/x86_64-redhat-linux-gnu/libclang_rt.asan.so+0xd5a83) (BuildId: c59bbd28ceb74038a60373d4a8cd4c258bcf0b4e)
TEST-54-CREDS.sh[1074]:     #1 0x55cf8cd16bb7 in malloc_multiply /usr/src/debug/systemd/src/basic/alloc-util.h:119:16
TEST-54-CREDS.sh[1074]:     #2 0x55cf8cd16bb7 in sd_json_variant_new_object /usr/src/debug/systemd/src/libsystemd/sd-json/sd-json.c:737:13
TEST-54-CREDS.sh[1074]:     #3 0x55cf8cd32e58 in json_parse_internal /usr/src/debug/systemd/src/libsystemd/sd-json/sd-json.c:3161:29
TEST-54-CREDS.sh[1074]:     systemd#4 0x55cf8cd37326 in sd_json_parse_with_source /usr/src/debug/systemd/src/libsystemd/sd-json/sd-json.c:3408:16
TEST-54-CREDS.sh[1074]:     systemd#5 0x55cf8cd37326 in sd_json_parse /usr/src/debug/systemd/src/libsystemd/sd-json/sd-json.c:3437:16
TEST-54-CREDS.sh[1074]:     systemd#6 0x55cf8cd3f753 in varlink_parse_message /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:962:13
TEST-54-CREDS.sh[1074]:     systemd#7 0x55cf8cd3f753 in sd_varlink_process /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:1466:13
TEST-54-CREDS.sh[1074]:     systemd#8 0x55cf8cd4c0a9 in sd_varlink_call_full /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:2160:21
TEST-54-CREDS.sh[1074]:     systemd#9 0x55cf8cd4d617 in sd_varlink_callb_ap /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:2237:16
TEST-54-CREDS.sh[1074]:     systemd#10 0x55cf8cd4da3c in sd_varlink_callb /usr/src/debug/systemd/src/libsystemd/sd-varlink/sd-varlink.c:2251:13
TEST-54-CREDS.sh[1074]:     systemd#11 0x55cf8cb47686 in ipc_decrypt_credential /usr/src/debug/systemd/src/shared/creds-util.c:1623:13
TEST-54-CREDS.sh[1074]:     systemd#12 0x55cf8caca99a in maybe_decrypt_and_write_credential /usr/src/debug/systemd/src/core/exec-credential.c:486:29
TEST-54-CREDS.sh[1074]:     systemd#13 0x55cf8cac790b in load_credential /usr/src/debug/systemd/src/core/exec-credential.c:713:16
TEST-54-CREDS.sh[1074]:     systemd#14 0x55cf8cac5403 in acquire_credentials /usr/src/debug/systemd/src/core/exec-credential.c:819:29
TEST-54-CREDS.sh[1074]:     systemd#15 0x55cf8cac5403 in setup_credentials_internal /usr/src/debug/systemd/src/core/exec-credential.c:1023:13
TEST-54-CREDS.sh[1074]:     systemd#16 0x55cf8cac42d4 in exec_setup_credentials /usr/src/debug/systemd/src/core/exec-credential.c:1168:21
TEST-54-CREDS.sh[1074]:     systemd#17 0x55cf8ca59569 in exec_invoke /usr/src/debug/systemd/src/core/exec-invoke.c:4866:13
TEST-54-CREDS.sh[1074]:     systemd#18 0x55cf8ca428d8 in run /usr/src/debug/systemd/src/core/executor.c:244:13
TEST-54-CREDS.sh[1074]:     systemd#19 0x55cf8ca428d8 in main /usr/src/debug/systemd/src/core/executor.c:275:13
TEST-54-CREDS.sh[1074]:     systemd#20 0x7f64b40110c7 in __libc_start_call_main (/lib64/libc.so.6+0x40c7) (BuildId: 159846287d47eef88f2a478f59803f6e8fc81d05)
TEST-54-CREDS.sh[1074]:     systemd#21 0x7f64b401118a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x418a) (BuildId: 159846287d47eef88f2a478f59803f6e8fc81d05)
TEST-54-CREDS.sh[1074]:     systemd#22 0x55cf8ca41cb4  (/usr/lib/systemd/systemd-executor+0x124cb4) (BuildId: 24f2b1608c3aaee3226cdd14fa2b6e6741156222)
TEST-54-CREDS.sh[1074]: SUMMARY: AddressSanitizer: heap-use-after-free /usr/src/debug/systemd/src/libsystemd/sd-json/sd-json.c:887:16 in sd_json_variant_unref
TEST-54-CREDS.sh[1074]: Shadow bytes around the buggy address:
TEST-54-CREDS.sh[1074]:   0x50c000000680: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
TEST-54-CREDS.sh[1074]:   0x50c000000700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
TEST-54-CREDS.sh[1074]:   0x50c000000780: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
TEST-54-CREDS.sh[1074]:   0x50c000000800: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
TEST-54-CREDS.sh[1074]:   0x50c000000880: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa
TEST-54-CREDS.sh[1074]: =>0x50c000000900: fa fa fa fa fa fa fa fa fd fd fd[fd]fd fd fd fd
TEST-54-CREDS.sh[1074]:   0x50c000000980: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa
TEST-54-CREDS.sh[1074]:   0x50c000000a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
TEST-54-CREDS.sh[1074]:   0x50c000000a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
TEST-54-CREDS.sh[1074]:   0x50c000000b00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
TEST-54-CREDS.sh[1074]:   0x50c000000b80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
TEST-54-CREDS.sh[1074]: Shadow byte legend (one shadow byte represents 8 application bytes):
TEST-54-CREDS.sh[1074]:   Addressable:           00
TEST-54-CREDS.sh[1074]:   Partially addressable: 01 02 03 04 05 06 07
TEST-54-CREDS.sh[1074]:   Heap left redzone:       fa
TEST-54-CREDS.sh[1074]:   Freed heap region:       fd
TEST-54-CREDS.sh[1074]:   Stack left redzone:      f1
TEST-54-CREDS.sh[1074]:   Stack mid redzone:       f2
TEST-54-CREDS.sh[1074]:   Stack right redzone:     f3
TEST-54-CREDS.sh[1074]:   Stack after return:      f5
TEST-54-CREDS.sh[1074]:   Stack use after scope:   f8
TEST-54-CREDS.sh[1074]:   Global redzone:          f9
TEST-54-CREDS.sh[1074]:   Global init order:       f6
TEST-54-CREDS.sh[1074]:   Poisoned by user:        f7
TEST-54-CREDS.sh[1074]:   Container overflow:      fc
TEST-54-CREDS.sh[1074]:   Array cookie:            ac
TEST-54-CREDS.sh[1074]:   Intra object redzone:    bb
TEST-54-CREDS.sh[1074]:   ASan internal:           fe
TEST-54-CREDS.sh[1074]:   Left alloca redzone:     ca
TEST-54-CREDS.sh[1074]:   Right alloca redzone:    cb

Follow-up for 2c3cbc5
poettering pushed a commit that referenced this pull request Apr 15, 2025
When trying to calculate the next firing of 'hourly', we'd lose the
tm_isdst value on the next iteration.

On most systems in Europe/Dublin it would cause a 100% cpu hang due to
timers restarting.

This happens in Europe/Dublin because Ireland defines the Irish Standard Time
as UTC+1, so winter time is encoded in tzdata as negative 1 hour of daylight
saving.

Before this patch:
$ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly'
  Original form: hourly
Normalized form: *-*-* *:00:00
    Next elapse: Sat 2025-03-29 23:00:00 GMT
       (in UTC): Sat 2025-03-29 23:00:00 UTC
       From now: 13h ago
   Iteration #2: Sun 2025-03-30 00:00:00 GMT
       (in UTC): Sun 2025-03-30 00:00:00 UTC
       From now: 12h ago
   Iteration #3: Sun 2025-03-30 00:00:00 GMT  <-- note every next iteration having the same firing time
       (in UTC): Sun 2025-03-30 00:00:00 UTC
       From now: 12h ago
...

With this patch:
$ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly'
  Original form: hourly
Normalized form: *-*-* *:00:00
    Next elapse: Sat 2025-03-29 23:00:00 GMT
       (in UTC): Sat 2025-03-29 23:00:00 UTC
       From now: 13h ago
   Iteration #2: Sun 2025-03-30 00:00:00 GMT
       (in UTC): Sun 2025-03-30 00:00:00 UTC
       From now: 12h ago
   Iteration #3: Sun 2025-03-30 02:00:00 IST  <-- the expected 1 hour jump
       (in UTC): Sun 2025-03-30 01:00:00 UTC
       From now: 11h ago
...

This bug isn't reproduced on Debian and Ubuntu because they mitigate it by
using the rearguard version of tzdata. ArchLinux and NixOS don't, so it would
cause pid1 to spin during DST transition.

This is how the affected tzdata looks like:
$ zdump -V -c 2024,2025 Europe/Dublin
Europe/Dublin  Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=1 gmtoff=0
Europe/Dublin  Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 IST isdst=0 gmtoff=3600
Europe/Dublin  Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 IST isdst=0 gmtoff=3600
Europe/Dublin  Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=1 gmtoff=0

Compare it to Europe/London:
$ zdump -V -c 2024,2025 Europe/London
Europe/London  Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=0 gmtoff=0
Europe/London  Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 BST isdst=1 gmtoff=3600
Europe/London  Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 BST isdst=1 gmtoff=3600
Europe/London  Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=0 gmtoff=0

Fixes systemd#32039.
poettering pushed a commit that referenced this pull request May 9, 2025
…r() and friends

The buffer will be used by a library outside of our code base,
and may not be initialized even on success. Let's initialize
them for safety.

Hopefully fixes the following fuzzer warning:
```
==2039==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f9ad8be3ae6 in _nss_files_getsgnam_r (/lib/x86_64-linux-gnu/libnss_files.so.2+0x8ae6) (BuildId: 013bf05b4846ebbdbebdb05585acc9726c2fabce)
    #1 0x7f9ad93e5902 in getsgnam_r (/lib/x86_64-linux-gnu/libc.so.6+0x126902) (BuildId: 0323ab4806bee6f846d9ad4bccfc29afdca49a58)
    #2 0x7f9ad9b98153 in nss_sgrp_for_group /work/build/../../src/systemd/src/shared/user-record-nss.c:357:21
    #3 0x7f9ad9b98926 in nss_group_record_by_gid /work/build/../../src/systemd/src/shared/user-record-nss.c:431:21
    systemd#4 0x7f9ad9bcebd7 in groupdb_by_gid_fallbacks /work/build/../../src/systemd/src/shared/userdb.c:1372:29

  Uninitialized value was created by a heap allocation
    #0 0x556fd5294302 in malloc /src/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:1021:3
    #1 0x7f9ad9b9811d in nss_sgrp_for_group /work/build/../../src/systemd/src/shared/user-record-nss.c:353:23
    #2 0x7f9ad9b98926 in nss_group_record_by_gid /work/build/../../src/systemd/src/shared/user-record-nss.c:431:21
    #3 0x7f9ad9bcebd7 in groupdb_by_gid_fallbacks /work/build/../../src/systemd/src/shared/userdb.c:1372:29
```
poettering pushed a commit that referenced this pull request May 15, 2025
The following failure should be in libxkbcommon and/or sanitizer.
There is nothing we can do here. Let's skip it.

```
TEST-73-LOCALE.sh[3733]: + assert_rc 0 localectl set-keymap lv
TEST-73-LOCALE.sh[6699]: + set +ex
TEST-73-LOCALE.sh[6700]: Failed to set keymap: Remote peer disconnected
TEST-73-LOCALE.sh[6703]: FAIL: expected: '0' actual: '1'
TEST-73-LOCALE.sh[157]: + rm -f /etc/dbus-1/system.d/systemd-localed-read-only.conf
[FAILED] Failed to start TEST-73-LOCALE.service - TEST-73-LOCALE.
```
```
==3719==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fa51f161000 at pc 0x7fa521250be4 bp 0x7ffe49130a80 sp 0x7ffe49130240
READ of size 19126 at 0x7fa51f161000 thread T0
    #0 0x7fa521250be3 in strndup (/usr/lib/clang/20/lib/x86_64-redhat-linux-gnu/libclang_rt.asan.so+0x50be3) (BuildId: aa6231e817f72469c44a6c6cee9f0694a87db7fb)
    #1 0x7fa51f128325  (/lib64/libxkbcommon.so.0+0x1c325) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
    #2 0x7fa51f121952  (/lib64/libxkbcommon.so.0+0x15952) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
    #3 0x7fa51f123d3a  (/lib64/libxkbcommon.so.0+0x17d3a) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
    systemd#4 0x7fa51f117c86  (/lib64/libxkbcommon.so.0+0xbc86) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
    systemd#5 0x7fa51f12548f  (/lib64/libxkbcommon.so.0+0x1948f) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
    systemd#6 0x7fa51f125c9e  (/lib64/libxkbcommon.so.0+0x19c9e) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
    systemd#7 0x7fa51f126a59  (/lib64/libxkbcommon.so.0+0x1aa59) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
    systemd#8 0x7fa51f12cec6  (/lib64/libxkbcommon.so.0+0x20ec6) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
    systemd#9 0x7fa51f12e3c2  (/lib64/libxkbcommon.so.0+0x223c2) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
    systemd#10 0x7fa51f12a4e5 in xkb_keymap_new_from_names (/lib64/libxkbcommon.so.0+0x1e4e5) (BuildId: 72e8cb985db37963272d140f7b2aee551c465ff5)
    systemd#11 0x5574dd63f864 in verify_xkb_rmlvo /usr/src/debug/systemd/src/locale/xkbcommon-util.c:69:14
(snip)
```
poettering added a commit that referenced this pull request Jul 7, 2025
I am pretty sure that "UKI" is the best known name for type #2 boot
loader spec entries, hence we really should put it in the name.
poettering pushed a commit that referenced this pull request Aug 18, 2025
When check_access() was added, the callback data parameter
was changed from a pointer to a double pointer, resulting
in a crash when it is accessed when logging an error:

 #0  __internal_syscall_cancel (a1=a1@entry=0, a2=a2@entry=0,
a3=a3@entry=140726176497168, a4=a4@entry=4, a5=a5@entry=0,
a6=a6@entry=0, nr=247) at ./nptl/cancellation.c:44
 #1  0x00007f5d0ec996ad in __syscall_cancel (a1=a1@entry=0,
a2=a2@entry=0, a3=a3@entry=140726176497168, a4=a4@entry=4,
a5=a5@entry=0, a6=a6@entry=0, nr=247) at ./nptl/cancellation.c:75
 #2  0x00007f5d0ed047ab in __waitid (idtype=idtype@entry=P_ALL,
id=id@entry=0, infop=infop@entry=0x7ffd5dc2be10,
options=options@entry=4) at ../sysdeps/unix/sysv/linux/waitid.c:29
 #3  0x00007f5d0f044412 in freeze () at ../src/basic/process-util.c:2039
 systemd#4  0x00005568f181bc2a in freeze_or_exit_or_reboot () at
../src/core/crash-handler.c:55
 systemd#5  0x00005568f181be82 in crash (sig=<optimized out>, siginfo=<optimized
out>, context=<optimized out>) at ../src/core/crash-handler.c:184
 systemd#6  <signal handler called>
 systemd#7  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
 systemd#8  0x00007f5d0ec6e300 in __printf_buffer (buf=buf@entry=0x7ffd5dc2ca90,
format=0x7f5d0f196e60 "%s: Failed to acquire credentials: %m",
ap=0x7ffd5dc2d3d0, mode_flags=2) at
./stdio-common/vfprintf-process-arg.c:435
 systemd#9  0x00007f5d0ec91daf in __vsnprintf_internal
(string=string@entry=0x7ffd5dc2cb70 "", maxlen=maxlen@entry=2048,
format=format@entry=0x7f5d0f196e60 "%s: Failed to acquire credentials:
%m", args=args@entry=0x7ffd5dc2d3d0, mode_flags=mode_flags@entry=2)
    at ./libio/vsnprintf.c:96
 systemd#10 0x00007f5d0ed27044 in ___vsnprintf_chk (s=s@entry=0x7ffd5dc2cb70 "",
maxlen=maxlen@entry=2048, flag=flag@entry=1, slen=slen@entry=2048,
format=format@entry=0x7f5d0f196e60 "%s: Failed to acquire credentials:
%m", ap=ap@entry=0x7ffd5dc2d3d0)
    at ./debug/vsnprintf_chk.c:34
 systemd#11 0x00007f5d0f02de59 in vsnprintf (__s=0x7ffd5dc2cb70 "", __n=2048,
__fmt=0x7f5d0f196e60 "%s: Failed to acquire credentials: %m",
__ap=0x7ffd5dc2d3d0) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:100
 systemd#12 log_internalv (level=7, error=-9, file=0x7f5d0f196643
"src/libsystemd/sd-varlink/sd-varlink.c", line=2853, func=0x7f5d0f1d5ca0
<__func__.62> "sd_varlink_get_peer_uid", format=0x7f5d0f196e60 "%s:
Failed to acquire credentials: %m",
    ap=0x7ffd5dc2d3d0) at ../src/basic/log.c:865
 systemd#13 0x00007f5d0f02ded5 in log_internalv (level=<optimized out>,
error=<optimized out>, file=<optimized out>, line=<optimized out>,
func=<optimized out>, format=<optimized out>, ap=0x7ffd5dc2d3d0) at
../src/basic/log.c:868
 systemd#14 0x00007f5d0f02df67 in log_internal (level=<optimized out>,
error=<optimized out>, file=<optimized out>, line=<optimized out>,
func=<optimized out>, format=<optimized out>) at ../src/basic/log.c:882
 systemd#15 0x00007f5d0f10a135 in sd_varlink_get_peer_uid (v=0x7f5d0f5ab110
<__func__.44>, ret=ret@entry=0x7ffd5dc2d4f0) at
../src/libsystemd/sd-varlink/sd-varlink.c:2853
 systemd#16 0x00007f5d0f50c29e in audit_callback (auditdata=0x7ffd5dc2d698,
cls=<optimized out>, msgbuf=0x55692366e77d "", msgbufsize=995) at
../src/core/selinux-access.c:65
 systemd#17 0x00007f5d0f716079 in avc_suppl_audit (ptr=0x7ffd5dc2d698, class=95,
buf=<optimized out>, len=<optimized out>) at ./src/avc_internal.h:101
 systemd#18 avc_audit (ssid=0x5569237f2890, tsid=0x556922d7f4b0,
tclass=<optimized out>, requested=<optimized out>, avd=<optimized out>,
result=0, a=0x7ffd5dc2d698) at ./src/avc.c:721
 systemd#19 0x00007f5d0f716367 in avc_has_perm (ssid=0x5569237f2890,
tsid=0x556922d7f4b0, tclass=tclass@entry=95, requested=4,
aeref=aeref@entry=0x0, auditdata=auditdata@entry=0x7ffd5dc2d698) at
./src/avc.c:836
 systemd#20 0x00007f5d0f718b0a in selinux_check_access
(scon=scon@entry=0x55692384cbc0 "system_u:system_r:policykit_t:s0",
tcon=tcon@entry=0x556922c98a20
"system_u:object_r:systemd_networkd_unit_t:s0",
class=class@entry=0x7f5d0f580b9e "service",
    perm=perm@entry=0x7f5d0f580cc0 "status",
aux=aux@entry=0x7ffd5dc2d698) at ./src/checkAccess.c:64
 systemd#21 0x00007f5d0f50bf7e in check_access (scon=0x55692384cbc0
"system_u:system_r:policykit_t:s0", tcon=0x556922c98a20
"system_u:object_r:systemd_networkd_unit_t:s0", tclass=0x7f5d0f580b9e
"service", permission=permission@entry=0x7f5d0f580cc0 "status",
    audit_info=<optimized out>, audit_info@entry=0x7ffd5dc2d720,
error=error@entry=0x7ffd5dc2d880) at ../src/core/selinux-access.c:229
 systemd#22 0x00007f5d0f5100a1 in mac_selinux_access_check_bus_internal
(message=<optimized out>, unit=<optimized out>,
permission=0x7f5d0f580cc0 "status", function=0x7f5d0f5ab110
<__func__.44> "method_get_unit_by_pidfd", error=0x7ffd5dc2d880)
    at ../src/core/selinux-access.c:329
 systemd#23 0x00007f5d0f4a024b in method_get_unit_by_pidfd
(message=0x5569236d9010, userdata=<optimized out>, error=0x7ffd5dc2d880)
at ../src/core/dbus-manager.c:657
 systemd#24 0x00007f5d0f0c9bd0 in method_callbacks_run (bus=0x5569238684e0,
m=0x5569236d9010, c=<optimized out>, require_fallback=false,
found_object=0x7ffd5dc2d947) at ../src/libsystemd/sd-bus/bus-objects.c:413
 systemd#25 object_find_and_run (bus=bus@entry=0x5569238684e0,
m=m@entry=0x5569236d9010, p=<optimized out>,
require_fallback=require_fallback@entry=false,
found_object=found_object@entry=0x7ffd5dc2d947) at
../src/libsystemd/sd-bus/bus-objects.c:1323
 systemd#26 0x00007f5d0f0cafa2 in bus_process_object (bus=0x5569238684e0,
m=0x5569236d9010) at ../src/libsystemd/sd-bus/bus-objects.c:1443
 systemd#27 0x00007f5d0f0d8c3e in process_message (bus=0x5569238684e0,
m=0x5569236d9010) at ../src/libsystemd/sd-bus/sd-bus.c:3006
 systemd#28 process_running (bus=0x5569238684e0, ret=0x0) at
../src/libsystemd/sd-bus/sd-bus.c:3048
 systemd#29 bus_process_internal (bus=bus@entry=0x5569238684e0,
ret=ret@entry=0x0) at ../src/libsystemd/sd-bus/sd-bus.c:3275
 systemd#30 0x00007f5d0f0d9099 in sd_bus_process (bus=bus@entry=0x5569238684e0,
ret=ret@entry=0x0) at ../src/libsystemd/sd-bus/sd-bus.c:3302
 systemd#31 0x00007f5d0f0db3ec in io_callback (s=<optimized out>, fd=<optimized
out>, revents=<optimized out>, userdata=0x5569238684e0) at
../src/libsystemd/sd-bus/sd-bus.c:3643
 systemd#32 0x00007f5d0f0a53d9 in source_dispatch (s=s@entry=0x5569236dea60) at
../src/libsystemd/sd-event/sd-event.c:4163
 systemd#33 0x00007f5d0f0a563d in sd_event_dispatch (e=<optimized out>,
e@entry=0x5569232f6c00) at ../src/libsystemd/sd-event/sd-event.c:4782
 systemd#34 0x00007f5d0f0a6d38 in sd_event_run (e=<optimized out>,
timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:4843
 systemd#35 0x00007f5d0f4f7871 in manager_loop (m=m@entry=0x5569232f8250) at
../src/core/manager.c:3310
 systemd#36 0x00005568f181517d in invoke_main_loop (m=0x5569232f8250,
saved_rlimit_nofile=0x7ffd5dc2dcb0, saved_rlimit_memlock=0x7ffd5dc2dca0,
ret_retval=<synthetic pointer>, ret_fds=0x7ffd5dc2dc78,
ret_switch_root_dir=<synthetic pointer>,
    ret_switch_root_init=<synthetic pointer>,
ret_error_message=0x7ffd5dc2dc90) at ../src/core/main.c:2140
 systemd#37 main (argc=<optimized out>, argv=0x7ffd5dc2dfe8) at
../src/core/main.c:3351

Follow-up for fe3f2ac
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