virt: handle Virtualbox 5.0 with kvm hypervisor #1

aszlig · 2015-09-17T14:50:12Z

This essentially is a backport of e32886e to fix NixOS/nixpkgs#systemd#9876 as applied in NixOS/nixpkgs@389e654.

Virtualbox 5.0 now supports kvm hypervisor. In this case cpuid identidies as "kvm", which breaks units depending on ConditionVirtualization=oracle. So return "oracle" even with kvm hypervisor. (cherry picked from commit e32886e)

This makes systemctl robust regarding journal truncation. This is a follow-up for 2cf4172 Fixes: Core was generated by `./systemctl status systemd-journald'. Program terminated with signal SIGBUS, Bus error. PID 8569 - core TID 8569: #0 0x00007f246cc89ed6 __memcmp_sse4_1 #1 0x0000557ebbc6f42c journal_file_init_header #2 0x0000557ebbc77262 journal_file_open #3 0x0000557ebbc42999 file_type_wanted #4 0x0000557ebbc42e08 add_any_file #5 0x0000557ebbc43832 add_directory #6 0x0000557ebbc4401c add_root_directory #7 0x0000557ebbc442e9 add_root_directory #8 0x0000557ebbc446fc add_search_paths #9 0x0000557ebbbacb5e show_journal_by_unit #10 0x0000557ebbb8376d print_status_info #11 0x0000557ebbb86a0b show_one #12 0x0000557ebbb87954 show #13 0x0000557ebbc20b1f dispatch_verb #14 0x0000557ebbb90615 systemctl_main #15 0x0000557ebbb9159f main #16 0x00007f246cb3e731 __libc_start_main #17 0x0000557ebbb75ae9 _start

It was meant to write to q instead of t FAIL: test-id128 ================ ================================================================= ==125770==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd4615bd31 at pc 0x7a2f41b1bf33 bp 0x7ffd4615b750 sp 0x7ffd4615b748 WRITE of size 1 at 0x7ffd4615bd31 thread T0 #0 0x7a2f41b1bf32 in id128_to_uuid_string src/libsystemd/sd-id128/id128-util.c:42 NixOS#1 0x401f73 in main src/test/test-id128.c:147 NixOS#2 0x7a2f41336341 in __libc_start_main (/lib64/libc.so.6+0x20341) NixOS#3 0x401129 in _start (/home/crrodriguez/scm/systemd/.libs/test-id128+0x401129) Address 0x7ffd4615bd31 is located in stack of thread T0 at offset 1409 in frame #0 0x401205 in main src/test/test-id128.c:37 This frame has 23 object(s): [32, 40) 'b' [96, 112) 'id' [160, 176) 'id2' [224, 240) 'a' [288, 304) 'b' [352, 368) 'a' [416, 432) 'b' [480, 496) 'a' [544, 560) 'b' [608, 624) 'a' [672, 688) 'b' [736, 752) 'a' [800, 816) 'b' [864, 880) 'a' [928, 944) 'b' [992, 1008) 'a' [1056, 1072) 'b' [1120, 1136) 'a' [1184, 1200) 'b' [1248, 1264) 'a' [1312, 1328) 'b' [1376, 1409) 't' <== Memory access at offset 1409 overflows this variable [1472, 1509) 'q' HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow src/libsystemd/sd-id128/id128-util.c:42 in id128_to_uuid_string Shadow bytes around the buggy address: 0x100028c23750: f2 f2 00 00 f4 f4 f2 f2 f2 f2 00 00 f4 f4 f2 f2 0x100028c23760: f2 f2 00 00 f4 f4 f2 f2 f2 f2 00 00 f4 f4 f2 f2 0x100028c23770: f2 f2 00 00 f4 f4 f2 f2 f2 f2 00 00 f4 f4 f2 f2 0x100028c23780: f2 f2 00 00 f4 f4 f2 f2 f2 f2 00 00 f4 f4 f2 f2 0x100028c23790: f2 f2 00 00 f4 f4 f2 f2 f2 f2 00 00 f4 f4 f2 f2 =>0x100028c237a0: f2 f2 00 00 00 00[01]f4 f4 f4 f2 f2 f2 f2 00 00 0x100028c237b0: 00 00 05 f4 f4 f4 00 00 00 00 00 00 00 00 00 00 0x100028c237c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100028c237d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100028c237e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100028c237f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==125770==ABORTING FAIL test-id128 (exit status: 1)

Fixes: $ sudo make run QEMU_BIN=/usr/bin/qemu-system-x86_64 KERNEL_APPEND=systemd.unit=multi-user.target SKIP_INITRD=yes TEST RUN: Basic systemd setup + /usr/bin/qemu-system-x86_64 -smp 1 -net none -m 512M -nographic -kernel /boot/vmlinuz-4.6.7-200.fc23.x86_64 -drive format=raw,cache=unsafe,file=/var/tmp/systemd-test.izx99J/rootdisk.img -append 'root=/dev/sda1 raid=noautodetect loglevel=2 init=/usr/lib/systemd/systemd-under-valgrind rw console=ttyS0 selinux=0 systemd.unified_cgroup_hierarchy=no systemd.unit=multi-user.target ' valgrind: warning (non-fatal): readlink("/proc/self/exe") failed. valgrind: continuing, however --trace-children=yes will not work. --1:0: aspacem Valgrind: FATAL: can't open /proc/self/maps --1:0: aspacem Exiting now. [ 3.152367] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 3.152367] [ 3.152367] CPU: 0 PID: 1 Comm: memcheck-amd64- Not tainted 4.6.7-200.fc23.x86_64 NixOS#1 [ 3.152367] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.8.2-20150714_191134- 04/01/2014 [ 3.152367] 0000000000000086 0000000047ca1666 ffff88001ea43e00 ffffffff813d954e [ 3.152367] ffffffff81a205a0 ffff88001ea43e98 ffff88001ea43e88 ffffffff811b5557 [ 3.152367] ffffffff00000010 ffff88001ea43e98 ffff88001ea43e30 0000000047ca1666 [ 3.152367] Call Trace: [ 3.152367] [<ffffffff813d954e>] dump_stack+0x63/0x85 [ 3.152367] [<ffffffff811b5557>] panic+0xde/0x220 [ 3.152367] [<ffffffff810ab9c3>] do_exit+0xb43/0xb50 [ 3.152367] [<ffffffff810aba57>] do_group_exit+0x47/0xb0 [ 3.152367] [<ffffffff810abad4>] SyS_exit_group+0x14/0x20 [ 3.152367] [<ffffffff817dae72>] entry_SYSCALL_64_fastpath+0x1a/0xa4 [ 3.152367] Kernel Offset: disabled [ 3.152367] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 3.152367] QEMU: Terminated

Fixes: Oct 20 09:10:49 systemd-sysusers[144]: Direct leak of 20 byte(s) in 1 object(s) allocated from: Oct 20 09:10:49 systemd-sysusers[144]: #0 0x7f3565a13e60 in malloc (/lib64/libasan.so.3+0xc6e60) Oct 20 09:10:49 systemd-sysusers[144]: NixOS#1 0x7f3565526bd0 in malloc_multiply src/basic/alloc-util.h:70 Oct 20 09:10:49 systemd-sysusers[144]: NixOS#2 0x7f356552cb55 in tempfn_xxxxxx src/basic/fileio.c:1116 Oct 20 09:10:49 systemd-sysusers[144]: NixOS#3 0x7f356552c4f0 in fopen_temporary src/basic/fileio.c:1042 Oct 20 09:10:49 systemd-sysusers[144]: NixOS#4 0x7f356555e00e in fopen_temporary_label src/basic/fileio-label.c:63 Oct 20 09:10:49 systemd-sysusers[144]: NixOS#5 0x56197c4a1766 in make_backup src/sysusers/sysusers.c:209 Oct 20 09:10:49 systemd-sysusers[144]: NixOS#6 0x56197c4a6335 in write_files src/sysusers/sysusers.c:710 Oct 20 09:10:49 systemd-sysusers[144]: NixOS#7 0x56197c4ae571 in main src/sysusers/sysusers.c:1817 Oct 20 09:10:49 systemd-sysusers[144]: NixOS#8 0x7f3564dee730 in __libc_start_main (/lib64/libc.so.6+0x20730)

bash-4.3# journalctl --no-hostname >/dev/null ================================================================= ==288==ERROR: LeakSanitizer: detected memory leaks Direct leak of 48492 byte(s) in 2694 object(s) allocated from: #0 0x7fb4aba13e60 in malloc (/lib64/libasan.so.3+0xc6e60) NixOS#1 0x7fb4ab5b2cc4 in malloc_multiply src/basic/alloc-util.h:70 NixOS#2 0x7fb4ab5b3194 in parse_field src/shared/logs-show.c:98 NixOS#3 0x7fb4ab5b4918 in output_short src/shared/logs-show.c:347 NixOS#4 0x7fb4ab5b7cb7 in output_journal src/shared/logs-show.c:977 NixOS#5 0x5650e29cd83d in main src/journal/journalctl.c:2581 NixOS#6 0x7fb4aabdb730 in __libc_start_main (/lib64/libc.so.6+0x20730) SUMMARY: AddressSanitizer: 48492 byte(s) leaked in 2694 allocation(s). Closes: systemd#4568

"%d (%m) %s\n" crashes asan: google/sanitizers#759 So, let's place %m after %s Fixes: ``` $ ./libtool --mode=execute ./test-selinux ... ============ test_misc ========== ASAN:DEADLYSIGNAL ================================================================= ==2981==ERROR: AddressSanitizer: SEGV on unknown address 0x000041b58ab3 (pc 0x7fd9c55a0eb2 bp 0x7fffdc2f9640 sp 0x7fffdc2f8d68 T0) #0 0x7fd9c55a0eb1 (/lib64/libasan.so.3+0xdeeb1) NixOS#1 0x7fd9c5550bbf (/lib64/libasan.so.3+0x8ebbf) NixOS#2 0x7fd9c5552cdd in __interceptor_vsnprintf (/lib64/libasan.so.3+0x90cdd) NixOS#3 0x7fd9c5063715 in log_internalv src/basic/log.c:680 NixOS#4 0x7fd9c506390a in log_internal src/basic/log.c:697 NixOS#5 0x561d398181a2 in test_misc src/test/test-selinux.c:81 NixOS#6 0x561d398185e8 in main src/test/test-selinux.c:117 NixOS#7 0x7fd9c493a400 in __libc_start_main (/lib64/libc.so.6+0x20400) NixOS#8 0x561d39817859 in _start (/home/vagrant/systemd-asan/.libs/lt-test-selinux+0x1859) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib64/libasan.so.3+0xdeeb1) ==2981==ABORTING ```

Fixes: ``` touch hola.service systemctl link $(pwd)/hola.service $(pwd)/hola.service ``` ``` ==1==ERROR: AddressSanitizer: attempting double-free on 0x60300002c560 in thread T0 (systemd): #0 0x7fc8c961cb00 in free (/lib64/libasan.so.3+0xc6b00) NixOS#1 0x7fc8c90ebd3b in strv_clear src/basic/strv.c:83 NixOS#2 0x7fc8c90ebdb6 in strv_free src/basic/strv.c:89 NixOS#3 0x55637c758c77 in strv_freep src/basic/strv.h:37 NixOS#4 0x55637c763ba9 in method_enable_unit_files_generic src/core/dbus-manager.c:1960 NixOS#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001 NixOS#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418 NixOS#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255 NixOS#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371 NixOS#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563 NixOS#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605 NixOS#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837 NixOS#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856 NixOS#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126 NixOS#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268 NixOS#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627 NixOS#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686 NixOS#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274 NixOS#18 0x55637c6a2194 in main src/core/main.c:1920 NixOS#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400) NixOS#20 0x55637c697339 in _start (/usr/lib/systemd/systemd+0xcd339) 0x60300002c560 is located 0 bytes inside of 19-byte region [0x60300002c560,0x60300002c573) freed by thread T0 (systemd) here: #0 0x7fc8c961cb00 in free (/lib64/libasan.so.3+0xc6b00) NixOS#1 0x7fc8c90ee320 in strv_remove src/basic/strv.c:630 NixOS#2 0x7fc8c90ee190 in strv_uniq src/basic/strv.c:602 NixOS#3 0x7fc8c9180533 in unit_file_link src/shared/install.c:1996 NixOS#4 0x55637c763b25 in method_enable_unit_files_generic src/core/dbus-manager.c:1985 NixOS#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001 NixOS#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418 NixOS#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255 NixOS#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371 NixOS#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563 NixOS#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605 NixOS#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837 NixOS#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856 NixOS#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126 NixOS#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268 NixOS#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627 NixOS#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686 NixOS#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274 NixOS#18 0x55637c6a2194 in main src/core/main.c:1920 NixOS#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400) previously allocated by thread T0 (systemd) here: #0 0x7fc8c95b0160 in strdup (/lib64/libasan.so.3+0x5a160) NixOS#1 0x7fc8c90edf32 in strv_extend src/basic/strv.c:552 NixOS#2 0x7fc8c923ae41 in bus_message_read_strv_extend src/libsystemd/sd-bus/bus-message.c:5578 NixOS#3 0x7fc8c923b0de in sd_bus_message_read_strv src/libsystemd/sd-bus/bus-message.c:5600 NixOS#4 0x55637c7639d1 in method_enable_unit_files_generic src/core/dbus-manager.c:1969 NixOS#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001 NixOS#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418 NixOS#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255 NixOS#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371 NixOS#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563 NixOS#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605 NixOS#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837 NixOS#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856 NixOS#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126 NixOS#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268 NixOS#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627 NixOS#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686 NixOS#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274 NixOS#18 0x55637c6a2194 in main src/core/main.c:1920 NixOS#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400) SUMMARY: AddressSanitizer: double-free (/lib64/libasan.so.3+0xc6b00) in free ==1==ABORTING ``` Closes systemd#5015

The simplest way to reproduce: ```diff diff --git a/src/libsystemd-network/test-dhcp6-client.c b/src/libsystemd-network/test-dhcp6-client.c index bd289fa..7b0a5ef 100644 --- a/src/libsystemd-network/test-dhcp6-client.c +++ b/src/libsystemd-network/test-dhcp6-client.c @@ -168,7 +168,7 @@ static uint8_t msg_advertise[198] = { 0x00, 0x17, 0x00, 0x10, 0x20, 0x01, 0x0d, 0xb8, 0xde, 0xad, 0xbe, 0xef, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x18, 0x00, 0x0b, - 0x03, 0x6c, 0x61, 0x62, 0x05, 0x69, 0x6e, 0x74, + 0x01, 0x6c, 0x01, 0x62, 0x00, 0x0a, 0x6e, 0x74, 0x72, 0x61, 0x00, 0x00, 0x1f, 0x00, 0x10, 0x20, 0x01, 0x0d, 0xb8, 0xde, 0xad, 0xbe, 0xef, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, @@ -338,9 +338,7 @@ static int test_advertise_option(sd_event *e) { assert_se(!memcmp(addrs, &msg_advertise[124], r * 16)); r = sd_dhcp6_lease_get_domains(lease, &domains); - assert_se(r == 1); - assert_se(!strcmp("lab.intra", domains[0])); - assert_se(domains[1] == NULL); + assert_se(r == -ENOENT); r = sd_dhcp6_lease_get_ntp_addrs(lease, &addrs); assert_se(r == 1); ``` Fixes: ``` ================================================================= ==15043==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7f13c8564160 in strdup (/lib64/libasan.so.3+0x5a160) NixOS#1 0x7f13c7caaf69 in strv_extend src/basic/strv.c:552 NixOS#2 0x55f775787230 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 NixOS#3 0x55f775788b96 in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 NixOS#4 0x55f775774b95 in test_advertise_option src/libsystemd-network/test-dhcp6-client.c:287 NixOS#5 0x55f77577883e in main src/libsystemd-network/test-dhcp6-client.c:759 NixOS#6 0x7f13c7589400 in __libc_start_main (/lib64/libc.so.6+0x20400) Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7f13c8564160 in strdup (/lib64/libasan.so.3+0x5a160) NixOS#1 0x7f13c7caaf69 in strv_extend src/basic/strv.c:552 NixOS#2 0x55f775787230 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 NixOS#3 0x55f775788b96 in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 NixOS#4 0x55f775781348 in client_parse_message src/libsystemd-network/sd-dhcp6-client.c:807 NixOS#5 0x55f775781ba2 in client_receive_advertise src/libsystemd-network/sd-dhcp6-client.c:895 NixOS#6 0x55f775782453 in client_receive_message src/libsystemd-network/sd-dhcp6-client.c:994 NixOS#7 0x7f13c7e447f4 in source_dispatch src/libsystemd/sd-event/sd-event.c:2268 NixOS#8 0x7f13c7e471b0 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627 NixOS#9 0x7f13c7e47ab3 in sd_event_run src/libsystemd/sd-event/sd-event.c:2686 NixOS#10 0x7f13c7e47c21 in sd_event_loop src/libsystemd/sd-event/sd-event.c:2706 NixOS#11 0x55f77577863c in test_client_solicit src/libsystemd-network/test-dhcp6-client.c:737 NixOS#12 0x55f77577884b in main src/libsystemd-network/test-dhcp6-client.c:760 NixOS#13 0x7f13c7589400 in __libc_start_main (/lib64/libc.so.6+0x20400) SUMMARY: AddressSanitizer: 8 byte(s) leaked in 2 allocation(s). ```

The simplest way to reproduce: ```diff diff --git a/src/libsystemd-network/test-dhcp6-client.c b/src/libsystemd-network/test-dhcp6-client.c index bd289fa..4e14d8f 100644 --- a/src/libsystemd-network/test-dhcp6-client.c +++ b/src/libsystemd-network/test-dhcp6-client.c @@ -286,6 +286,8 @@ static int test_advertise_option(sd_event *e) { assert_se(optlen == 11); assert_se(dhcp6_lease_set_domains(lease, optval, optlen) >= 0); + assert_se(dhcp6_lease_set_domains(lease, optval, + optlen) >= 0); break; case SD_DHCP6_OPTION_SNTP_SERVERS: ``` Fixes: ``` ==27369==ERROR: LeakSanitizer: detected memory leaks Direct leak of 10 byte(s) in 1 object(s) allocated from: #0 0x7f90e7d21160 in strdup (/lib64/libasan.so.3+0x5a160) NixOS#1 0x7f90e7467f69 in strv_extend src/basic/strv.c:552 NixOS#2 0x5612fcc19379 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 NixOS#3 0x5612fcc1acdf in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 NixOS#4 0x5612fcc06b95 in test_advertise_option src/libsystemd-network/test-dhcp6-client.c:287 NixOS#5 0x5612fcc0a987 in main src/libsystemd-network/test-dhcp6-client.c:761 NixOS#6 0x7f90e6d46400 in __libc_start_main (/lib64/libc.so.6+0x20400) SUMMARY: AddressSanitizer: 10 byte(s) leaked in 1 allocation(s). ```

We would only log a terse message when pid1 or systemd-journald crashed. It seems better to reuse the normal code paths as much as possible, with the following differences: - if pid1 crashes, we cannot launch the helper, so we don't analyze the coredump, just write it to file directly from the helper invoked by the kernel; - if journald crashes, we can produce the backtrace, but we don't log full structured messages. With comparison to previous code, advantages are: - we go through most of the steps, so for example vacuuming is performed, - we gather and log more data. In particular for journald and pid1 crashes we generate a backtrace, and for pid1 crashes we record the metadata (fdinfo, maps, etc.), - coredumpctl shows pid1 crashes. A disavantage (inefficiency) is that we gather metadata for journald crashes which is then ignored because _TRANSPORT=kernel does not support structued messages. Messages for the systemd-journald "crash" have _TRANSPORT=kernel, and _TRANSPORT=journal for the pid1 "crash". Feb 26 16:27:55 systemd[1]: systemd-journald.service: Main process exited, code=dumped, status=11/SEGV Feb 26 16:27:55 systemd[1]: systemd-journald.service: Unit entered failed state. Feb 26 16:37:54 systemd-coredump[18801]: Process 18729 (systemd-journal) of user 0 dumped core. Feb 26 16:37:54 systemd-coredump[18801]: Coredump diverted to /var/lib/systemd/coredump/core.systemd-journal.0.36c14bf3c6ce4c38914f441038990979.18729.1488145074000000.lz4 Feb 26 16:37:54 systemd-coredump[18801]: Stack trace of thread 18729: Feb 26 16:37:54 systemd-coredump[18801]: #0 0x00007f46d6a06b8d fsync (libpthread.so.0) Feb 26 16:37:54 systemd-coredump[18801]: NixOS#1 0x00007f46d71bfc47 journal_file_set_online (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: NixOS#2 0x00007f46d71c1c31 journal_file_append_object (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: NixOS#3 0x00007f46d71c3405 journal_file_append_data (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: NixOS#4 0x00007f46d71c4b7c journal_file_append_entry (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: NixOS#5 0x00005577688cf056 write_to_journal (systemd-journald) Feb 26 16:37:54 systemd-coredump[18801]: NixOS#6 0x00005577688d2e98 dispatch_message_real (systemd-journald) Feb 26 16:37:54 kernel: systemd-coredum: 9 output lines suppressed due to ratelimiting Feb 26 16:37:54 systemd-journald[18810]: Journal started Feb 26 16:50:59 systemd-coredump[19229]: Due to PID 1 having crashed coredump collection will now be turned off. Feb 26 16:51:00 systemd[1]: Caught <SEGV>, dumped core as pid 19228. Feb 26 16:51:00 systemd[1]: Freezing execution. Feb 26 16:51:00 systemd-coredump[19229]: Process 19228 (systemd) of user 0 dumped core. Stack trace of thread 19228: #0 0x00007fab82075c47 kill (libc.so.6) NixOS#1 0x000055fdf7c38b6b crash (systemd) NixOS#2 0x00007fab824175c0 __restore_rt (libpthread.so.0) NixOS#3 0x00007fab82148573 epoll_wait (libc.so.6) NixOS#4 0x00007fab8366f84a sd_event_wait (libsystemd-shared-233.so) NixOS#5 0x00007fab836701de sd_event_run (libsystemd-shared-233.so) NixOS#6 0x000055fdf7c4a380 manager_loop (systemd) NixOS#7 0x000055fdf7c402c2 main (systemd) NixOS#8 0x00007fab82060401 __libc_start_main (libc.so.6) NixOS#9 0x000055fdf7c3818a _start (systemd) Poor machine ;)

So don't even try to added the filter to reduce noise. The test is updated to skip calling _sysctl because the kernel prints an oops-like message that is confusing and unhelpful: Jul 15 21:07:01 rpi3 kernel: test-seccomp[8448]: syscall -10080 Jul 15 21:07:01 rpi3 kernel: Code: aa0503e4 aa0603e5 aa0703e6 d4000001 (b13ffc1f) Jul 15 21:07:01 rpi3 kernel: CPU: 3 PID: 8448 Comm: test-seccomp Tainted: G W 4.11.8-300.fc26.aarch64 NixOS#1 Jul 15 21:07:01 rpi3 kernel: Hardware name: raspberrypi rpi/rpi, BIOS 2017.05 06/24/2017 Jul 15 21:07:01 rpi3 kernel: task: ffff80002bb0bb00 task.stack: ffff800036354000 Jul 15 21:07:01 rpi3 kernel: PC is at 0xffff8669c7c4 Jul 15 21:07:01 rpi3 kernel: LR is at 0xaaaac64b6750 Jul 15 21:07:01 rpi3 kernel: pc : [<0000ffff8669c7c4>] lr : [<0000aaaac64b6750>] pstate: 60000000 Jul 15 21:07:01 rpi3 kernel: sp : 0000ffffdc640fd0 Jul 15 21:07:01 rpi3 kernel: x29: 0000ffffdc640fd0 x28: 0000000000000000 Jul 15 21:07:01 rpi3 kernel: x27: 0000000000000000 x26: 0000000000000000 Jul 15 21:07:01 rpi3 kernel: x25: 0000000000000000 x24: 0000000000000000 Jul 15 21:07:01 rpi3 kernel: x23: 0000000000000000 x22: 0000000000000000 Jul 15 21:07:01 rpi3 kernel: x21: 0000aaaac64b4940 x20: 0000000000000000 Jul 15 21:07:01 rpi3 kernel: x19: 0000aaaac64b88f8 x18: 0000000000000020 Jul 15 21:07:01 rpi3 kernel: x17: 0000ffff8669c7a0 x16: 0000aaaac64d2ee0 Jul 15 21:07:01 rpi3 kernel: x15: 0000000000000000 x14: 0000000000000000 Jul 15 21:07:01 rpi3 kernel: x13: 203a657275746365 x12: 0000000000000000 Jul 15 21:07:01 rpi3 kernel: x11: 0000ffffdc640418 x10: 0000000000000000 Jul 15 21:07:01 rpi3 kernel: x9 : 0000000000000005 x8 : 00000000ffffd8a0 Jul 15 21:07:01 rpi3 kernel: x7 : 7f7f7f7f7f7f7f7f x6 : 7f7f7f7f7f7f7f7f Jul 15 21:07:01 rpi3 kernel: x5 : 65736d68716f7277 x4 : 0000000000000000 Jul 15 21:07:01 rpi3 kernel: x3 : 0000000000000008 x2 : 0000000000000000 Jul 15 21:07:01 rpi3 kernel: x1 : 0000000000000000 x0 : 0000000000000000 Jul 15 21:07:01 rpi3 kernel: (cherry picked from commit 1e20e640132c700c23494bb9e2619afb83878380)

In general we'd leak anything that was allocated in the first parsing of netdev, e.g. netdev name, host name, etc. Use normal netdev_unref to make sure everything is freed. --- command --- /home/zbyszek/src/systemd/build2/test-network --- stderr --- /etc/systemd/network/wg0.netdev:3: Failed to parse netdev kind, ignoring: wireguard /etc/systemd/network/wg0.netdev:5: Unknown section 'WireGuard'. Ignoring. /etc/systemd/network/wg0.netdev:9: Unknown section 'WireGuardPeer'. Ignoring. NetDev has no Kind configured in /etc/systemd/network/wg0.netdev. Ignoring /etc/systemd/network/br0.network:13: Unknown lvalue 'NetDev' in section 'Network' br0: netdev ready ================================================================= ==11666==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7f3a314cf238 in __interceptor_strdup (/lib64/libasan.so.4+0x77238) NixOS#1 0x7f3a30e71ad1 in free_and_strdup ../src/basic/string-util.c:870 NixOS#2 0x7f3a30d34fba in config_parse_ifname ../src/shared/conf-parser.c:981 NixOS#3 0x7f3a30d2f5b0 in next_assignment ../src/shared/conf-parser.c:155 NixOS#4 0x7f3a30d30303 in parse_line ../src/shared/conf-parser.c:273 NixOS#5 0x7f3a30d30dee in config_parse ../src/shared/conf-parser.c:390 NixOS#6 0x7f3a30d310a5 in config_parse_many_files ../src/shared/conf-parser.c:428 NixOS#7 0x7f3a30d3181c in config_parse_many ../src/shared/conf-parser.c:487 NixOS#8 0x55b4200f9b00 in netdev_load_one ../src/network/netdev/netdev.c:634 NixOS#9 0x55b4200fb562 in netdev_load ../src/network/netdev/netdev.c:778 NixOS#10 0x55b4200c607a in manager_load_config ../src/network/networkd-manager.c:1299 NixOS#11 0x55b4200818e0 in test_load_config ../src/network/test-network.c:128 NixOS#12 0x55b42008343b in main ../src/network/test-network.c:254 NixOS#13 0x7f3a305f8889 in __libc_start_main (/lib64/libc.so.6+0x20889) SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s). -------

Some versions of asan report the following false positive when strict_string_checks=1 is passed: ================================================================= ==3297==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f64e4090286 bp 0x7ffe46acd9a0 sp 0x7ffe46acd118 T0) ==3297==The signal is caused by a READ memory access. ==3297==Hint: address points to the zero page. #0 0x7f64e4090285 in __strlen_sse2 (/lib64/libc.so.6+0xaa285) #1 0x7f64e5a51e46 (/lib64/libasan.so.4+0x41e46) #2 0x7f64e4e5e3a0 (/lib64/libglib-2.0.so.0+0x383a0) #3 0x7f64e4e5e536 in g_dgettext (/lib64/libglib-2.0.so.0+0x38536) #4 0x7f64e48fac5f (/lib64/libgio-2.0.so.0+0xc1c5f) #5 0x7f64e4c03978 in g_type_class_ref (/lib64/libgobject-2.0.so.0+0x30978) #6 0x7f64e4be9567 in g_object_new_with_properties (/lib64/libgobject-2.0.so.0+0x16567) #7 0x7f64e4be9fd0 in g_object_new (/lib64/libgobject-2.0.so.0+0x16fd0) #8 0x7f64e48fd43e in g_dbus_message_new_from_blob (/lib64/libgio-2.0.so.0+0xc443e) #9 0x564a6aa0de52 in main ../src/libsystemd/sd-bus/test-bus-marshal.c:228 #10 0x7f64e4007009 in __libc_start_main (/lib64/libc.so.6+0x21009) #11 0x564a6aa0a569 in _start (/home/vagrant/systemd/build/test-bus-marshal+0x5569) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0xaa285) in __strlen_sse2 ==3297==ABORTING It's an external library and errors in external libraries are generally not very useful for looking for internal bugs. It would be better not to change the code and use standard suppression techinques decribed at https://clang.llvm.org/docs/AddressSanitizer.html#suppressing-reports-in-external-libraries, but, unfortunaley, none of them seems to be able to suppress fatal errors in asan intself.

Fuzzing with AddressSanitizer reports an error here: ==11==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7fe53f5497d8 at pc 0x7fe53ef055c9 bp 0x7ffd344e9380 sp 0x7ffd344e9378 READ of size 4 at 0x7fe53f5497d8 thread T0 SCARINESS: 27 (4-byte-read-global-buffer-overflow-far-from-bounds) #0 0x7fe53ef055c8 in bus_error_name_to_errno /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:118:24 #1 0x7fe53ef0577b in bus_error_setfv /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:274:17 #2 0x7fe53ef0595a in sd_bus_error_setf /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:284:21 #3 0x561059 in manager_load_unit_prepare /work/build/../../src/systemd/src/core/manager.c #4 0x560680 in manager_load_unit /work/build/../../src/systemd/src/core/manager.c:1773:13 #5 0x5d49a6 in unit_add_dependency_by_name /work/build/../../src/systemd/src/core/unit.c:2882:13 #6 0x538996 in config_parse_unit_deps /work/build/../../src/systemd/src/core/load-fragment.c:152:21 #7 0x6db771 in next_assignment /work/build/../../src/systemd/src/shared/conf-parser.c:155:32 #8 0x6d697e in parse_line /work/build/../../src/systemd/src/shared/conf-parser.c:273:16 #9 0x6d5c48 in config_parse /work/build/../../src/systemd/src/shared/conf-parser.c:390:21 #10 0x535678 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-unit-file.c:41:16 #11 0x73bd60 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:517:13 #12 0x73a39f in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:442:3 #13 0x73d9bc in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:650:19 #14 0x73fa05 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:773:5 #15 0x71f75d in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:754:6 #16 0x71285c in main /src/libfuzzer/FuzzerMain.cpp:20:10 #17 0x7fe53da0482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #18 0x430e68 in _start (/out/fuzz-unit-file+0x430e68) 0x7fe53f5497d8 is located 8 bytes to the right of global variable 'bus_common_errors' defined in '../../src/systemd/src/libsystemd/sd-bus/bus-common-errors.c:28:51' (0x7fe53f549300) of size 1232 SUMMARY: AddressSanitizer: global-buffer-overflow /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:118:24 in bus_error_name_to_errno Shadow bytes around the buggy address: 0x0ffd27ea12a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffd27ea12b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffd27ea12c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffd27ea12d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffd27ea12e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0ffd27ea12f0: 00 00 00 00 00 00 00 00 00 00 f9[f9]f9 f9 f9 f9 0x0ffd27ea1300: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 0x0ffd27ea1310: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 0x0ffd27ea1320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffd27ea1330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffd27ea1340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==11==ABORTING but I think it's a false positive because of our low-level magic in how this area is constructed.

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

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

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

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

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

virt: handle Virtualbox 5.0 with kvm hypervisor

de75901

Virtualbox 5.0 now supports kvm hypervisor. In this case cpuid identidies as "kvm", which breaks units depending on ConditionVirtualization=oracle. So return "oracle" even with kvm hypervisor. (cherry picked from commit e32886e)

edolstra merged commit de75901 into NixOS:nixos-v217 Sep 17, 2015

aszlig deleted the vbox5-fix branch September 17, 2015 14:54

aszlig mentioned this pull request Dec 11, 2015

Fix VirtualBox systemd-detect-virt again #3

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

virt: handle Virtualbox 5.0 with kvm hypervisor #1

virt: handle Virtualbox 5.0 with kvm hypervisor #1

aszlig commented Sep 17, 2015

virt: handle Virtualbox 5.0 with kvm hypervisor #1

virt: handle Virtualbox 5.0 with kvm hypervisor #1

Conversation

aszlig commented Sep 17, 2015