mount: use libmount to monitor mountinfo & utab#9
Conversation
The current implementation directly monitor /proc/self/mountinfo and /run/mount/utab files. It's really not optimal because utab file is private libmount stuff without any official guaranteed semantic. The libmount since v2.26 provides API to monitor mount kernel & userspace changes. This patch replaces the current implementation with libmount based solution. Now the manager.h includes <libmount.h>, so $MOUNT_CFLAGS has been necessary to add to many tests CFLAGS. Note that mnt_monitor_event_cleanup() in v2.26 is broken, so the patch uses mnt_monitor_next_change(). It's exactly the same solution which uses the current libmount HEAD (mnt_monitor_event_cleanup() is API shorcut only).
msekletar
referenced
this pull request
in msekletar/systemd
Jun 2, 2015
$ /usr/lib/systemd/systemd-timedated (wait until auto-exit)
=================================================================
==396==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 928 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1)
#1 0x562a83ae60cf in bus_message_from_header src/libsystemd/sd-bus/bus-message.c:480
#2 0x562a83ae6f5a in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:576
#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#9 0x562a83aae1af in main src/timedate/timedated.c:730
#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
Indirect leak of 77 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788f6a in realloc (/usr/lib64/libasan.so.2+0x96f6a)
#1 0x562a83ad418a in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:963
#2 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#3 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#4 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
#5 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#6 0x562a83aae1af in main src/timedate/timedated.c:730
#7 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
Indirect leak of 2 byte(s) in 1 object(s) allocated from:
#0 0x7f782f75493f in strdup (/usr/lib64/libasan.so.2+0x6293f)
#1 0x562a83b0229b in bus_message_parse_fields src/libsystemd/sd-bus/bus-message.c:5382
#2 0x562a83ae7290 in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:601
#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
#9 0x562a83aae1af in main src/timedate/timedated.c:730
#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
SUMMARY: AddressSanitizer: 1007 byte(s) leaked in 3 allocation(s).
This is due to missing _cleanup_bus_message_unref_ in context_read_ntp()
Contributor
|
I have send a new version to the mailing list. (For the next patches I'll use pull requests.) |
Contributor
Author
|
Obsoleted with #53 |
mischief
pushed a commit
to mischief/systemd
that referenced
this pull request
Jun 12, 2015
rules: whitelist xvd* devices
whot
pushed a commit
to whot/systemd
that referenced
this pull request
Jul 30, 2015
$ /usr/lib/systemd/systemd-timedated (wait until auto-exit)
=================================================================
==396==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 928 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1)
systemd#1 0x562a83ae60cf in bus_message_from_header src/libsystemd/sd-bus/bus-message.c:480
systemd#2 0x562a83ae6f5a in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:576
systemd#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
systemd#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
systemd#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
systemd#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
systemd#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
systemd#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
systemd#9 0x562a83aae1af in main src/timedate/timedated.c:730
systemd#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
Indirect leak of 77 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788f6a in realloc (/usr/lib64/libasan.so.2+0x96f6a)
systemd#1 0x562a83ad418a in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:963
systemd#2 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
systemd#3 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
systemd#4 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
systemd#5 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
systemd#6 0x562a83aae1af in main src/timedate/timedated.c:730
systemd#7 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
Indirect leak of 2 byte(s) in 1 object(s) allocated from:
#0 0x7f782f75493f in strdup (/usr/lib64/libasan.so.2+0x6293f)
systemd#1 0x562a83b0229b in bus_message_parse_fields src/libsystemd/sd-bus/bus-message.c:5382
systemd#2 0x562a83ae7290 in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:601
systemd#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
systemd#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
systemd#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
systemd#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
systemd#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
systemd#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
systemd#9 0x562a83aae1af in main src/timedate/timedated.c:730
systemd#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
SUMMARY: AddressSanitizer: 1007 byte(s) leaked in 3 allocation(s).
This is due to missing _cleanup_bus_message_unref_ in context_read_ntp()
(cherry picked from commit 6b71bab)
Closed
evverx
referenced
this pull request
in evverx/systemd
Mar 14, 2016
Fixes:
Message: Process 806 (systemd-importd) of user 0 dumped core.
Stack trace of thread 806:
#0 0x00007f5eaeff7227 raise (libc.so.6)
#1 0x00007f5eaeff8e8a abort (libc.so.6)
#2 0x000055b6d3418f4f log_assert_failed (systemd-importd)
#3 0x000055b6d3409daf safe_close (systemd-importd)
#4 0x000055b6d33c25ea closep (systemd-importd)
#5 0x000055b6d33c38d9 setup_machine_directory (systemd-importd)
#6 0x000055b6d33b8536 method_pull_tar_or_raw (systemd-importd)
#7 0x000055b6d33ed097 method_callbacks_run (systemd-importd)
#8 0x000055b6d33ef929 object_find_and_run (systemd-importd)
#9 0x000055b6d33eff6b bus_process_object (systemd-importd)
#10 0x000055b6d3447f77 process_message (systemd-importd)
#11 0x000055b6d344815a process_running (systemd-importd)
#12 0x000055b6d3448a10 bus_process_internal (systemd-importd)
#13 0x000055b6d3448ae1 sd_bus_process (systemd-importd)
#14 0x000055b6d3449779 time_callback (systemd-importd)
#15 0x000055b6d3454ff4 source_dispatch (systemd-importd)
#16 0x000055b6d34562b9 sd_event_dispatch (systemd-importd)
#17 0x000055b6d34566f8 sd_event_run (systemd-importd)
#18 0x000055b6d33ba72a bus_event_loop_with_idle (systemd-importd)
#19 0x000055b6d33b95bc manager_run (systemd-importd)
#20 0x000055b6d33b9766 main (systemd-importd)
#21 0x00007f5eaefe2a00 __libc_start_main (libc.so.6)
#22 0x000055b6d33b5569 _start (systemd-importd)
lnykryn
pushed a commit
to lnykryn/systemd
that referenced
this pull request
Mar 23, 2016
$ /usr/lib/systemd/systemd-timedated (wait until auto-exit)
=================================================================
==396==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 928 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788db1 in __interceptor_calloc (/usr/lib64/libasan.so.2+0x96db1)
systemd#1 0x562a83ae60cf in bus_message_from_header src/libsystemd/sd-bus/bus-message.c:480
systemd#2 0x562a83ae6f5a in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:576
systemd#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
systemd#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
systemd#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
systemd#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
systemd#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
systemd#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
systemd#9 0x562a83aae1af in main src/timedate/timedated.c:730
systemd#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
Indirect leak of 77 byte(s) in 1 object(s) allocated from:
#0 0x7f782f788f6a in realloc (/usr/lib64/libasan.so.2+0x96f6a)
systemd#1 0x562a83ad418a in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:963
systemd#2 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
systemd#3 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
systemd#4 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
systemd#5 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
systemd#6 0x562a83aae1af in main src/timedate/timedated.c:730
systemd#7 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
Indirect leak of 2 byte(s) in 1 object(s) allocated from:
#0 0x7f782f75493f in strdup (/usr/lib64/libasan.so.2+0x6293f)
systemd#1 0x562a83b0229b in bus_message_parse_fields src/libsystemd/sd-bus/bus-message.c:5382
systemd#2 0x562a83ae7290 in bus_message_from_malloc src/libsystemd/sd-bus/bus-message.c:601
systemd#3 0x562a83ad3cad in bus_socket_make_message src/libsystemd/sd-bus/bus-socket.c:915
systemd#4 0x562a83ad4cfc in bus_socket_read_message src/libsystemd/sd-bus/bus-socket.c:1051
systemd#5 0x562a83ab733f in bus_read_message src/libsystemd/sd-bus/sd-bus.c:1647
systemd#6 0x562a83ab98ea in sd_bus_call src/libsystemd/sd-bus/sd-bus.c:2038
systemd#7 0x562a83b1f46d in sd_bus_call_method src/libsystemd/sd-bus/bus-convenience.c:94
systemd#8 0x562a83aab3e1 in context_read_ntp src/timedate/timedated.c:192
systemd#9 0x562a83aae1af in main src/timedate/timedated.c:730
systemd#10 0x7f782eb238c4 in __libc_start_main (/lib64/libc.so.6+0x208c4)
SUMMARY: AddressSanitizer: 1007 byte(s) leaked in 3 allocation(s).
This is due to missing _cleanup_bus_message_unref_ in context_read_ntp()
(cherry picked from commit 6b71bab)
Cherry-picked from: 6b71bab
Resolves: #1222517
lnykryn
added a commit
to lnykryn/systemd
that referenced
this pull request
Mar 23, 2016
Revert original NPIV support patch, instead use patch from systemd#2731
2 tasks
evverx
referenced
this pull request
in evverx/systemd
Jun 4, 2016
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
keszybz
pushed a commit
that referenced
this pull request
Jun 4, 2016
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
evverx
referenced
this pull request
in evverx/systemd
Jan 9, 2017
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)
#1 0x7fc8c90ebd3b in strv_clear src/basic/strv.c:83
#2 0x7fc8c90ebdb6 in strv_free src/basic/strv.c:89
#3 0x55637c758c77 in strv_freep src/basic/strv.h:37
#4 0x55637c763ba9 in method_enable_unit_files_generic src/core/dbus-manager.c:1960
#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
#18 0x55637c6a2194 in main src/core/main.c:1920
#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400)
#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)
#1 0x7fc8c90ee320 in strv_remove src/basic/strv.c:630
#2 0x7fc8c90ee190 in strv_uniq src/basic/strv.c:602
#3 0x7fc8c9180533 in unit_file_link src/shared/install.c:1996
#4 0x55637c763b25 in method_enable_unit_files_generic src/core/dbus-manager.c:1985
#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
#18 0x55637c6a2194 in main src/core/main.c:1920
#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)
#1 0x7fc8c90edf32 in strv_extend src/basic/strv.c:552
#2 0x7fc8c923ae41 in bus_message_read_strv_extend src/libsystemd/sd-bus/bus-message.c:5578
#3 0x7fc8c923b0de in sd_bus_message_read_strv src/libsystemd/sd-bus/bus-message.c:5600
#4 0x55637c7639d1 in method_enable_unit_files_generic src/core/dbus-manager.c:1969
#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
#18 0x55637c6a2194 in main src/core/main.c:1920
#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
evverx
referenced
this pull request
in evverx/systemd
Jan 9, 2017
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)
#1 0x7fc8c90ebd3b in strv_clear src/basic/strv.c:83
#2 0x7fc8c90ebdb6 in strv_free src/basic/strv.c:89
#3 0x55637c758c77 in strv_freep src/basic/strv.h:37
#4 0x55637c763ba9 in method_enable_unit_files_generic src/core/dbus-manager.c:1960
#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
#18 0x55637c6a2194 in main src/core/main.c:1920
#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400)
#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)
#1 0x7fc8c90ee320 in strv_remove src/basic/strv.c:630
#2 0x7fc8c90ee190 in strv_uniq src/basic/strv.c:602
#3 0x7fc8c9180533 in unit_file_link src/shared/install.c:1996
#4 0x55637c763b25 in method_enable_unit_files_generic src/core/dbus-manager.c:1985
#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
#18 0x55637c6a2194 in main src/core/main.c:1920
#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)
#1 0x7fc8c90edf32 in strv_extend src/basic/strv.c:552
#2 0x7fc8c923ae41 in bus_message_read_strv_extend src/libsystemd/sd-bus/bus-message.c:5578
#3 0x7fc8c923b0de in sd_bus_message_read_strv src/libsystemd/sd-bus/bus-message.c:5600
#4 0x55637c7639d1 in method_enable_unit_files_generic src/core/dbus-manager.c:1969
#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
#18 0x55637c6a2194 in main src/core/main.c:1920
#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
evverx
referenced
this pull request
in evverx/systemd
Jan 20, 2017
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) #1 0x7f13c7caaf69 in strv_extend src/basic/strv.c:552 #2 0x55f775787230 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 #3 0x55f775788b96 in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 #4 0x55f775774b95 in test_advertise_option src/libsystemd-network/test-dhcp6-client.c:287 #5 0x55f77577883e in main src/libsystemd-network/test-dhcp6-client.c:759 #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) #1 0x7f13c7caaf69 in strv_extend src/basic/strv.c:552 #2 0x55f775787230 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 #3 0x55f775788b96 in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 #4 0x55f775781348 in client_parse_message src/libsystemd-network/sd-dhcp6-client.c:807 #5 0x55f775781ba2 in client_receive_advertise src/libsystemd-network/sd-dhcp6-client.c:895 #6 0x55f775782453 in client_receive_message src/libsystemd-network/sd-dhcp6-client.c:994 #7 0x7f13c7e447f4 in source_dispatch src/libsystemd/sd-event/sd-event.c:2268 #8 0x7f13c7e471b0 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627 #9 0x7f13c7e47ab3 in sd_event_run src/libsystemd/sd-event/sd-event.c:2686 #10 0x7f13c7e47c21 in sd_event_loop src/libsystemd/sd-event/sd-event.c:2706 #11 0x55f77577863c in test_client_solicit src/libsystemd-network/test-dhcp6-client.c:737 #12 0x55f77577884b in main src/libsystemd-network/test-dhcp6-client.c:760 #13 0x7f13c7589400 in __libc_start_main (/lib64/libc.so.6+0x20400) SUMMARY: AddressSanitizer: 8 byte(s) leaked in 2 allocation(s). ```
keszybz
pushed a commit
that referenced
this pull request
Jan 24, 2017
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) #1 0x7f13c7caaf69 in strv_extend src/basic/strv.c:552 #2 0x55f775787230 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 #3 0x55f775788b96 in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 #4 0x55f775774b95 in test_advertise_option src/libsystemd-network/test-dhcp6-client.c:287 #5 0x55f77577883e in main src/libsystemd-network/test-dhcp6-client.c:759 #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) #1 0x7f13c7caaf69 in strv_extend src/basic/strv.c:552 #2 0x55f775787230 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 #3 0x55f775788b96 in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 #4 0x55f775781348 in client_parse_message src/libsystemd-network/sd-dhcp6-client.c:807 #5 0x55f775781ba2 in client_receive_advertise src/libsystemd-network/sd-dhcp6-client.c:895 #6 0x55f775782453 in client_receive_message src/libsystemd-network/sd-dhcp6-client.c:994 #7 0x7f13c7e447f4 in source_dispatch src/libsystemd/sd-event/sd-event.c:2268 #8 0x7f13c7e471b0 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627 #9 0x7f13c7e47ab3 in sd_event_run src/libsystemd/sd-event/sd-event.c:2686 #10 0x7f13c7e47c21 in sd_event_loop src/libsystemd/sd-event/sd-event.c:2706 #11 0x55f77577863c in test_client_solicit src/libsystemd-network/test-dhcp6-client.c:737 #12 0x55f77577884b in main src/libsystemd-network/test-dhcp6-client.c:760 #13 0x7f13c7589400 in __libc_start_main (/lib64/libc.so.6+0x20400) SUMMARY: AddressSanitizer: 8 byte(s) leaked in 2 allocation(s). ```
keszybz
referenced
this pull request
in keszybz/systemd
Feb 26, 2017
We would only log a terse message when pid1 or systemd-journald crashed. It seems better to follow the resuse 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 gather 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]: #1 0x00007f46d71bfc47 journal_file_set_online (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #2 0x00007f46d71c1c31 journal_file_append_object (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #3 0x00007f46d71c3405 journal_file_append_data (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #4 0x00007f46d71c4b7c journal_file_append_entry (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #5 0x00005577688cf056 write_to_journal (systemd-journald) Feb 26 16:37:54 systemd-coredump[18801]: #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) #1 0x000055fdf7c38b6b crash (systemd) #2 0x00007fab824175c0 __restore_rt (libpthread.so.0) #3 0x00007fab82148573 epoll_wait (libc.so.6) #4 0x00007fab8366f84a sd_event_wait (libsystemd-shared-233.so) #5 0x00007fab836701de sd_event_run (libsystemd-shared-233.so) #6 0x000055fdf7c4a380 manager_loop (systemd) #7 0x000055fdf7c402c2 main (systemd) #8 0x00007fab82060401 __libc_start_main (libc.so.6) #9 0x000055fdf7c3818a _start (systemd) Poor machine ;)
keszybz
referenced
this pull request
in keszybz/systemd
Feb 27, 2017
We would only log a terse message when pid1 or systemd-journald crashed. It seems better to follow the resuse 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 gather 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]: #1 0x00007f46d71bfc47 journal_file_set_online (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #2 0x00007f46d71c1c31 journal_file_append_object (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #3 0x00007f46d71c3405 journal_file_append_data (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #4 0x00007f46d71c4b7c journal_file_append_entry (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #5 0x00005577688cf056 write_to_journal (systemd-journald) Feb 26 16:37:54 systemd-coredump[18801]: #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) #1 0x000055fdf7c38b6b crash (systemd) #2 0x00007fab824175c0 __restore_rt (libpthread.so.0) #3 0x00007fab82148573 epoll_wait (libc.so.6) #4 0x00007fab8366f84a sd_event_wait (libsystemd-shared-233.so) #5 0x00007fab836701de sd_event_run (libsystemd-shared-233.so) #6 0x000055fdf7c4a380 manager_loop (systemd) #7 0x000055fdf7c402c2 main (systemd) #8 0x00007fab82060401 __libc_start_main (libc.so.6) #9 0x000055fdf7c3818a _start (systemd) Poor machine ;)
keszybz
referenced
this pull request
in keszybz/systemd
Mar 1, 2017
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]: #1 0x00007f46d71bfc47 journal_file_set_online (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #2 0x00007f46d71c1c31 journal_file_append_object (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #3 0x00007f46d71c3405 journal_file_append_data (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #4 0x00007f46d71c4b7c journal_file_append_entry (libsystemd-shared-233.so) Feb 26 16:37:54 systemd-coredump[18801]: #5 0x00005577688cf056 write_to_journal (systemd-journald) Feb 26 16:37:54 systemd-coredump[18801]: #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) #1 0x000055fdf7c38b6b crash (systemd) #2 0x00007fab824175c0 __restore_rt (libpthread.so.0) #3 0x00007fab82148573 epoll_wait (libc.so.6) #4 0x00007fab8366f84a sd_event_wait (libsystemd-shared-233.so) #5 0x00007fab836701de sd_event_run (libsystemd-shared-233.so) #6 0x000055fdf7c4a380 manager_loop (systemd) #7 0x000055fdf7c402c2 main (systemd) #8 0x00007fab82060401 __libc_start_main (libc.so.6) #9 0x000055fdf7c3818a _start (systemd) Poor machine ;)
2 tasks
keszybz
referenced
this pull request
in keszybz/systemd
May 25, 2017
encoder: fix two image size detection issues
whot
pushed a commit
to whot/systemd
that referenced
this pull request
Oct 10, 2017
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)
systemd#1 0x7fc8c90ebd3b in strv_clear src/basic/strv.c:83
systemd#2 0x7fc8c90ebdb6 in strv_free src/basic/strv.c:89
systemd#3 0x55637c758c77 in strv_freep src/basic/strv.h:37
systemd#4 0x55637c763ba9 in method_enable_unit_files_generic src/core/dbus-manager.c:1960
systemd#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
systemd#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
systemd#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
systemd#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
systemd#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
systemd#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
systemd#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
systemd#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
systemd#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
systemd#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
systemd#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
systemd#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
systemd#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
systemd#18 0x55637c6a2194 in main src/core/main.c:1920
systemd#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400)
systemd#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)
systemd#1 0x7fc8c90ee320 in strv_remove src/basic/strv.c:630
systemd#2 0x7fc8c90ee190 in strv_uniq src/basic/strv.c:602
systemd#3 0x7fc8c9180533 in unit_file_link src/shared/install.c:1996
systemd#4 0x55637c763b25 in method_enable_unit_files_generic src/core/dbus-manager.c:1985
systemd#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
systemd#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
systemd#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
systemd#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
systemd#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
systemd#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
systemd#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
systemd#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
systemd#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
systemd#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
systemd#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
systemd#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
systemd#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
systemd#18 0x55637c6a2194 in main src/core/main.c:1920
systemd#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)
systemd#1 0x7fc8c90edf32 in strv_extend src/basic/strv.c:552
systemd#2 0x7fc8c923ae41 in bus_message_read_strv_extend src/libsystemd/sd-bus/bus-message.c:5578
systemd#3 0x7fc8c923b0de in sd_bus_message_read_strv src/libsystemd/sd-bus/bus-message.c:5600
systemd#4 0x55637c7639d1 in method_enable_unit_files_generic src/core/dbus-manager.c:1969
systemd#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
systemd#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
systemd#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
systemd#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
systemd#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
systemd#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
systemd#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
systemd#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
systemd#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
systemd#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
systemd#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
systemd#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
systemd#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
systemd#18 0x55637c6a2194 in main src/core/main.c:1920
systemd#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
(cherry picked from commit 8af35ba)
Related: #1409997
evverx
referenced
this pull request
in evverx/systemd
May 5, 2020
Having taken a look at https://github.com/systemd/systemd/runs/645252074?check_suite_focus=true where fuzz-journal-remote failed with ``` AddressSanitizer:DEADLYSIGNAL ================================================================= ==16==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f864f98948e bp 0x7ffde5c6b7c0 sp 0x7ffde5c6b560 T0) ==16==The signal is caused by a READ memory access. ==16==Hint: address points to the zero page. SCARINESS: 10 (null-deref) #0 0x7f864f98948e in output_short /work/build/../../src/systemd/src/shared/logs-show.c #1 0x7f864f984624 in show_journal_entry /work/build/../../src/systemd/src/shared/logs-show.c:1154:15 #2 0x7f864f984b63 in show_journal /work/build/../../src/systemd/src/shared/logs-show.c:1239:21 #3 0x4cabab in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journal-remote.c:67:21 #4 0x51fd16 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:556:15 #5 0x51c330 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:470:3 #6 0x523700 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:765:7 #7 0x5246cd in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:792:3 #8 0x4de3d1 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:824:6 #9 0x4cfb47 in main /src/libfuzzer/FuzzerMain.cpp:19:10 #10 0x7f864e69782f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #11 0x41f2a8 in _start (out/fuzz-journal-remote+0x41f2a8) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /work/build/../../src/systemd/src/shared/logs-show.c in output_short ==16==ABORTING MS: 0 ; base unit: 0000000000000000000000000000000000000000 0x44,0x3d,0xa,0x5f,0x5f,0x52,0x45,0x41,0x4c,0x54,0x49,0x4d,0x45,0x5f,0x54,0x49,0x4d,0x45,0x53,0x54,0x41,0x4d,0x50,0x3d,0x31,0xa,0xa, D=\x0a__REALTIME_TIMESTAMP=1\x0a\x0a artifact_prefix='./'; Test unit written to ./crash-d635b9dd31cceff3c912fd45e1a58d7e90f0ad73 Base64: RD0KX19SRUFMVElNRV9USU1FU1RBTVA9MQoK ``` I was wondering why it hadn't been caught by the compiler even though clang should have failed to compile it with ``` ../src/shared/logs-show.c:624:25: warning: null passed to a callee that requires a non-null argument [-Wnonnull] print_multiline(f, 4 + fieldlen + 1, 0, OUTPUT_FULL_WIDTH, 0, false, ^ ../src/shared/logs-show.c:161:24: note: callee declares array parameter as static here size_t highlight[static 2]) { ^ ~~~~~~~~~~ ../src/shared/logs-show.c:1239:21: warning: null passed to a callee that requires a non-null argument [-Wnonnull] r = show_journal_entry(f, j, mode, n_columns, flags, NULL, NULL, ellipsized); ^ ~~~~ ../src/shared/logs-show.c:1133:30: note: callee declares array parameter as static here const size_t highlight[static 2], ^ ~~~~~~~~~~ 2 warnings generated. ``` Given that judging by systemd#13039 it doesn't seem to be the first time issues like that have been missed I think it would be better to turn nonnull on and get around false positives on a case-by-case basis with DISABLE_WARNING_NONNULL .. REENABLE_WARNING Reopens systemd#6119
keszybz
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 #4 0x51fd16 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:556:15 #5 0x51c330 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:470:3 #6 0x523700 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:765:7 #7 0x5246cd in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:792:3 #8 0x4de3d1 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:824:6 #9 0x4cfb47 in main /src/libfuzzer/FuzzerMain.cpp:19:10 #10 0x7f864e69782f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #11 0x41f2a8 in _start (out/fuzz-journal-remote+0x41f2a8) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /work/build/../../src/systemd/src/shared/logs-show.c in output_short ==16==ABORTING MS: 0 ; base unit: 0000000000000000000000000000000000000000 0x44,0x3d,0xa,0x5f,0x5f,0x52,0x45,0x41,0x4c,0x54,0x49,0x4d,0x45,0x5f,0x54,0x49,0x4d,0x45,0x53,0x54,0x41,0x4d,0x50,0x3d,0x31,0xa,0xa, D=\x0a__REALTIME_TIMESTAMP=1\x0a\x0a artifact_prefix='./'; Test unit written to ./crash-d635b9dd31cceff3c912fd45e1a58d7e90f0ad73 Base64: RD0KX19SRUFMVElNRV9USU1FU1RBTVA9MQoK ``` I was wondering why it hadn't been caught by the compiler even though clang should have failed to compile it with ``` ../src/shared/logs-show.c:624:25: warning: null passed to a callee that requires a non-null argument [-Wnonnull] print_multiline(f, 4 + fieldlen + 1, 0, OUTPUT_FULL_WIDTH, 0, false, ^ ../src/shared/logs-show.c:161:24: note: callee declares array parameter as static here size_t highlight[static 2]) { ^ ~~~~~~~~~~ ../src/shared/logs-show.c:1239:21: warning: null passed to a callee that requires a non-null argument [-Wnonnull] r = show_journal_entry(f, j, mode, n_columns, flags, NULL, NULL, ellipsized); ^ ~~~~ ../src/shared/logs-show.c:1133:30: note: callee declares array parameter as static here const size_t highlight[static 2], ^ ~~~~~~~~~~ 2 warnings generated. ``` Given that judging by #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 #6119
ssahani
referenced
this pull request
in ssahani/systemd
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)
#4 0x7faf3d6d7b1f (/lib64/libpthread.so.0+0x14b1f)
#5 0x7faf3d3c2624 in raise (/lib64/libc.so.6+0x3c624)
#6 0x7faf3d3ab8d8 in abort (/lib64/libc.so.6+0x258d8)
#7 0x7faf3e12593a in log_assert_failed_realm /home/vagrant/systemd/build/../src/basic/log.c:819:9
#8 0x7faf3e140ce1 in safe_atou8 /home/vagrant/systemd/build/../src/basic/parse-util.c:458:9
#9 0x68089c in config_parse_dhcp_send_option /home/vagrant/systemd/build/../src/network/networkd-dhcp-common.c:517:21
#10 0x7faf3debed4e in next_assignment /home/vagrant/systemd/build/../src/shared/conf-parser.c:132:32
#11 0x7faf3deb7783 in parse_line /home/vagrant/systemd/build/../src/shared/conf-parser.c:270:16
#12 0x7faf3deb606c in config_parse /home/vagrant/systemd/build/../src/shared/conf-parser.c:395:21
#13 0x7faf3deb85ee in config_parse_many_files /home/vagrant/systemd/build/../src/shared/conf-parser.c:452:21
#14 0x7faf3deb8c57 in config_parse_many /home/vagrant/systemd/build/../src/shared/conf-parser.c:511:16
#15 0x57c2eb in network_load_one /home/vagrant/systemd/build/../src/network/networkd-network.c:470:13
#16 0x543490 in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/network/fuzz-network-parser.c:26:16
#17 0x44e3e8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x44e3e8)
#18 0x433505 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x433505)
#19 0x43c449 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/out/fuzz-network-parser+0x43c449)
#20 0x42c4a6 in main (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4a6)
#21 0x7faf3d3ad1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
#22 0x42c4fd in _start (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4fd)
NOTE: libFuzzer has rudimentary signal handlers.
Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
```
ssahani
referenced
this pull request
in ssahani/systemd
May 22, 2020
```
$ printf '[DHCPv4]\nSendOption=1:uint8' >crash
$ ./out/fuzz-network-parser ./crash
INFO: Seed: 1158717610
INFO: Loaded 2 modules (199728 inline 8-bit counters): 136668 [0x7faf3e91a930, 0x7faf3e93bf0c), 63060 [0xadf190, 0xaee7e4),
INFO: Loaded 2 PC tables (199728 PCs): 136668 [0x7faf3e93bf10,0x7faf3eb51cd0), 63060 [0xaee7e8,0xbe4d28),
./out/fuzz-network-parser: Running 1 inputs 1 time(s) each.
Running: ./crash
Assertion 's' failed at src/basic/parse-util.c:458, function int safe_atou8(const char *, uint8_t *)(). Aborting.
==5588== ERROR: libFuzzer: deadly signal
#0 0x51811e in __sanitizer_print_stack_trace (/home/vagrant/systemd/out/fuzz-network-parser+0x51811e)
#1 0x46b921 in fuzzer::PrintStackTrace() (/home/vagrant/systemd/out/fuzz-network-parser+0x46b921)
#2 0x44ded6 in fuzzer::Fuzzer::CrashCallback() (.part.0) (/home/vagrant/systemd/out/fuzz-network-parser+0x44ded6)
#3 0x44df9d in fuzzer::Fuzzer::StaticCrashSignalCallback() (/home/vagrant/systemd/out/fuzz-network-parser+0x44df9d)
#4 0x7faf3d6d7b1f (/lib64/libpthread.so.0+0x14b1f)
#5 0x7faf3d3c2624 in raise (/lib64/libc.so.6+0x3c624)
#6 0x7faf3d3ab8d8 in abort (/lib64/libc.so.6+0x258d8)
#7 0x7faf3e12593a in log_assert_failed_realm /home/vagrant/systemd/build/../src/basic/log.c:819:9
#8 0x7faf3e140ce1 in safe_atou8 /home/vagrant/systemd/build/../src/basic/parse-util.c:458:9
#9 0x68089c in config_parse_dhcp_send_option /home/vagrant/systemd/build/../src/network/networkd-dhcp-common.c:517:21
#10 0x7faf3debed4e in next_assignment /home/vagrant/systemd/build/../src/shared/conf-parser.c:132:32
#11 0x7faf3deb7783 in parse_line /home/vagrant/systemd/build/../src/shared/conf-parser.c:270:16
#12 0x7faf3deb606c in config_parse /home/vagrant/systemd/build/../src/shared/conf-parser.c:395:21
#13 0x7faf3deb85ee in config_parse_many_files /home/vagrant/systemd/build/../src/shared/conf-parser.c:452:21
#14 0x7faf3deb8c57 in config_parse_many /home/vagrant/systemd/build/../src/shared/conf-parser.c:511:16
#15 0x57c2eb in network_load_one /home/vagrant/systemd/build/../src/network/networkd-network.c:470:13
#16 0x543490 in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/network/fuzz-network-parser.c:26:16
#17 0x44e3e8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x44e3e8)
#18 0x433505 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x433505)
#19 0x43c449 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/out/fuzz-network-parser+0x43c449)
#20 0x42c4a6 in main (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4a6)
#21 0x7faf3d3ad1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
#22 0x42c4fd in _start (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4fd)
NOTE: libFuzzer has rudimentary signal handlers.
Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
```
Closed
This was referenced Sep 8, 2021
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The current implementation directly monitor /proc/self/mountinfo and
/run/mount/utab files. It's really not optimal because utab file is
private libmount stuff without any official guaranteed semantic.
The libmount since v2.26 provides API to monitor mount kernel &
userspace changes. This patch replaces the current implementation with
libmount based solution.
Now the manager.h includes <libmount.h>, so $MOUNT_CFLAGS has been
necessary to add to many tests CFLAGS.
Note that mnt_monitor_event_cleanup() in v2.26 is broken, so the patch
uses mnt_monitor_next_change(). It's exactly the same solution which
uses the current libmount HEAD (mnt_monitor_event_cleanup() is API
shorcut only).