picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Systemd/test/fuzz/meson.build

44 lines
1.7 KiB
Meson
Raw Normal View History

Hook up oss-fuzz test cases as tests This is a bit painful because a separate build of systemd is necessary. The tests are guarded by tests!=false and slow-tests==true. Running them is not slow, but compilation certainly is. If this proves unwieldy, we can add a separate option controlling those builds later. The build for each sanitizer has its own directory, and we build all fuzzer tests there, and then pull them out one-by-one by linking into the target position as necessary. It would be nicer to just build the desired fuzzer, but we need to build the whole nested build as one unit. [I also tried making systemd and nested meson subproject. This would work nicely, but meson does not allow that because the nested target names are the same as the outer project names. If that is ever fixed, that would be the way to go.] v2: - make sure things still work if memory sanitizer is not available v3: - switch to syntax which works with meson 0.42.1 found in Ubuntu
2018-01-19 07:54:30 +01:00
# SPDX-License-Identifier: LGPL-2.1+
sanitize_address = custom_target(
'sanitize-address-fuzzers',
output : 'sanitize-address-fuzzers',
command : [meson_build_sh,
meson.source_root(),
'@OUTPUT@',
'fuzzers',
'-Db_lundef=false -Db_sanitize=address'])
test: run all fuzz regression tests with all sanitizers We currently have just one sanitizer for tests, asan, but we may add more in the future. So let's keep the loop over the sanitizers in meson.build, but just enable all regression cases under all sanitizers. If it fails under one of them, it might fail under a different one. In subsequent commits I'll add test cases which might not fail under asan, but it's good to commit them for future use. The test names are made more verbose: 256/257 fuzz-dns-packet:oss-fuzz-5465:address OK 0.04 s 257/257 fuzz-dns-packet:issue-7888:address OK 0.03 s
2018-03-14 14:27:04 +01:00
sanitizers = [['address', sanitize_address]]
Hook up oss-fuzz test cases as tests This is a bit painful because a separate build of systemd is necessary. The tests are guarded by tests!=false and slow-tests==true. Running them is not slow, but compilation certainly is. If this proves unwieldy, we can add a separate option controlling those builds later. The build for each sanitizer has its own directory, and we build all fuzzer tests there, and then pull them out one-by-one by linking into the target position as necessary. It would be nicer to just build the desired fuzzer, but we need to build the whole nested build as one unit. [I also tried making systemd and nested meson subproject. This would work nicely, but meson does not allow that because the nested target names are the same as the outer project names. If that is ever fixed, that would be the way to go.] v2: - make sure things still work if memory sanitizer is not available v3: - switch to syntax which works with meson 0.42.1 found in Ubuntu
2018-01-19 07:54:30 +01:00
fuzz_regression_tests = '''
tests: add a reproducer for the heap-buffer-overflow fixed in b387d3c1327a3ad2
2018-09-29 05:09:23 +02:00
fuzz-dhcp6-client/crash-4003c06fce43a11fbd22f02584df2807ac333eae
tests: add a reproducer for the heap-buffer-overflow fixed in cb1bdeaf56852275e6b ==14==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020001c761a at pc 0x000000540abc bp 0x7ffd0caf2c50 sp 0x7ffd0caf2c48 READ of size 2 at 0x6020001c761a thread T0 #0 0x540abb in client_parse_message /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:849:73 #1 0x53f3bc in client_receive_advertise /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:1083:13 #2 0x53d57f in client_receive_message /work/build/../../src/systemd/src/libsystemd-network/sd-dhcp6-client.c:1182:21 #3 0x7f71d8c3eeee in source_dispatch /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3042:21 #4 0x7f71d8c3e431 in sd_event_dispatch /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3455:21 #5 0x7f71d8c3fa8d in sd_event_run /work/build/../../src/systemd/src/libsystemd/sd-event/sd-event.c:3512:21 #6 0x531f2b in fuzz_client /work/build/../../src/systemd/src/fuzz/fuzz-dhcp6-client.c:44:9 #7 0x531bc1 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-dhcp6-client.c:53:9 #8 0x57bef8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:570:15 #9 0x579d97 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:479:3 #10 0x57dcc2 in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:707:19 #11 0x580cd6 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:838:5 #12 0x55e998 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:764:6 #13 0x551a4c in main /src/libfuzzer/FuzzerMain.cpp:20:10 #14 0x7f71d784182f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #15 0x41e928 in _start (/out/fuzz-dhcp6-client+0x41e928)
2018-09-29 05:25:34 +02:00
fuzz-dhcp6-client/crash-6e88fcb6b85c9436bcbe05219aa8e550194645ef
test: run all fuzz regression tests with all sanitizers We currently have just one sanitizer for tests, asan, but we may add more in the future. So let's keep the loop over the sanitizers in meson.build, but just enable all regression cases under all sanitizers. If it fails under one of them, it might fail under a different one. In subsequent commits I'll add test cases which might not fail under asan, but it's good to commit them for future use. The test names are made more verbose: 256/257 fuzz-dns-packet:oss-fuzz-5465:address OK 0.04 s 257/257 fuzz-dns-packet:issue-7888:address OK 0.03 s
2018-03-14 14:27:04 +01:00
fuzz-dns-packet/issue-7888
meson: add fuzz regressions to list Apparently I haven't been very good at remembering to do this.
2018-06-11 10:02:49 +02:00
fuzz-dns-packet/oss-fuzz-5465
fuzz-journal-remote/crash-5a8f03d4c3a46fcded39527084f437e8e4b54b76
fuzz-journal-remote/crash-96dee870ea66d03e89ac321eee28ea63a9b9aa45
basic/ellipsize: do not assume the string is NUL-terminated when length is given oss-fuzz flags this as: ==1==WARNING: MemorySanitizer: use-of-uninitialized-value 0. 0x7fce77519ca5 in ascii_is_valid systemd/src/basic/utf8.c:252:9 1. 0x7fce774d203c in ellipsize_mem systemd/src/basic/string-util.c:544:13 2. 0x7fce7730a299 in print_multiline systemd/src/shared/logs-show.c:244:37 3. 0x7fce772ffdf3 in output_short systemd/src/shared/logs-show.c:495:25 4. 0x7fce772f5a27 in show_journal_entry systemd/src/shared/logs-show.c:1077:15 5. 0x7fce772f66ad in show_journal systemd/src/shared/logs-show.c:1164:29 6. 0x4a2fa0 in LLVMFuzzerTestOneInput systemd/src/fuzz/fuzz-journal-remote.c:64:21 ... I didn't reproduce the issue, but this looks like an obvious error: the length is specified, so we shouldn't use the string with any functions for normal C-strings.
2018-06-09 13:41:44 +02:00
fuzz-journal-remote/oss-fuzz-8659
meson: add fuzz regressions to list Apparently I haven't been very good at remembering to do this.
2018-06-11 10:02:49 +02:00
fuzz-journal-remote/oss-fuzz-8686
tests: add reproducers for several issues uncovered with fuzz-journald-syslog This is a follow-up to a70f343cacf03ac51cdefb0d2e.
2018-09-02 20:13:31 +02:00
fuzz-journald-syslog/github-9795
fuzz-journald-syslog/github-9820
fuzz-journald-syslog/github-9827
fuzz-journald-syslog/github-9829
tests: add a reproducer for an infinite loop in ndisc_handle_datagram =0 ndisc_router_parse (rt=0x60d000000110) at ../src/libsystemd-network/ndisc-router.c:126 =1 0x000055555558dc67 in ndisc_handle_datagram (nd=0x608000000020, rt=0x60d000000110) at ../src/libsystemd-network/sd-ndisc.c:170 =2 0x000055555558e65d in ndisc_recv (s=0x611000000040, fd=4, revents=1, userdata=0x608000000020) at ../src/libsystemd-network/sd-ndisc.c:233 =3 0x00007ffff63913a8 in source_dispatch (s=0x611000000040) at ../src/libsystemd/sd-event/sd-event.c:3042 =4 0x00007ffff6395eab in sd_event_dispatch (e=0x617000000080) at ../src/libsystemd/sd-event/sd-event.c:3455 =5 0x00007ffff6396b12 in sd_event_run (e=0x617000000080, timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3512 =6 0x0000555555583f5c in LLVMFuzzerTestOneInput (data=0x6060000000e0 "\206", size=53) at ../src/fuzz/fuzz-ndisc-rs.c:422 =7 0x0000555555586356 in main (argc=2, argv=0x7fffffffe3d8) at ../src/fuzz/fuzz-main.c:33
2018-09-26 17:10:21 +02:00
fuzz-ndisc-rs/timeout-2815b773c712fa33bea62f541dfa3017c64ea2f1
tests: add a reproducer for another infinite loop in ndisc_handle_datagram
2018-09-26 20:09:09 +02:00
fuzz-ndisc-rs/timeout-61fff7fd1e5dcc07e1b656baab29065ce634ad5b
fuzz: commit test case for oss-fuzz issue 6884 This seems to be a false positive in msan: https://github.com/google/sanitizers/issues/767. I don't see anything wrong with the code either, and valgrind does not see the issue. Anyway, let's add the test case. We don't have msan hooked up yet, but hopefully we'll in the future. oss-fuzz #6884.
2018-03-14 14:31:24 +01:00
fuzz-unit-file/oss-fuzz-6884
shared/conf-parser: fix crash when specifiers cannot be resolved in config_parse_device_allow() oss-fuzz #6885.
2018-03-13 12:25:06 +01:00
fuzz-unit-file/oss-fuzz-6885
basic/calendarspec: fix assert crash when year is too large in calendarspec_from_time_t() gmtime_r() will return NULL in that case, and we would crash. I committed the reproducer case in fuzz-regressions/, even though we don't have ubsan hooked up yet. Let's add it anyway in case it is useful in the future. We actually crash anyway when compiled with asserts, so this can be easily reproduced without ubsan. oss-fuzz #6886.
2018-03-13 12:51:08 +01:00
fuzz-unit-file/oss-fuzz-6886
core/service: fix memleak of USBFunctionStrings and USBFunctionDescriptors oss-fuzz #6892.
2018-03-15 11:42:00 +01:00
fuzz-unit-file/oss-fuzz-6892
fuzz: add test case for oss-fuzz #6897 and a work-around The orignal reproducer from oss-fuzz depends on the hostname (via %H and %c). The hostname needs a dash for msan to report this, so a simpler case from @evverx with the dash hardcoded is also added. The issue is a false positive from msan, which does not instruct stpncpy (https://github.com/google/sanitizers/issues/926). Let's add a work-around until this is fixed.
2018-03-16 12:02:54 +01:00
fuzz-unit-file/oss-fuzz-6897
fuzz-unit-file/oss-fuzz-6897-evverx
core/load-fragment: reject overly long paths early No need to go through the specifier_printf() if the path is already too long in the unexpanded form (since specifiers increase the length of the string in all practical cases). In the oss-fuzz test case, valgrind reports: total heap usage: 179,044 allocs, 179,044 frees, 72,687,755,703 bytes allocated and the original config file is ~500kb. This isn't really a security issue, since the config file has to be trusted any way, but just a matter of preventing accidental resource exhaustion. https://oss-fuzz.com/v2/issue/4651449704251392/6977 While at it, fix order of arguments in the neighbouring log_syntax() call.
2018-03-19 15:43:35 +01:00
fuzz-unit-file/oss-fuzz-6908
fuzz-unit-file/oss-fuzz-6917
fuzz-unit-file/oss-fuzz-6977
meson: add fuzz regressions to list Apparently I haven't been very good at remembering to do this.
2018-06-11 10:02:49 +02:00
fuzz-unit-file/oss-fuzz-6977-unminimized
basic/calendarspec: add check for repeat values that would overflow https://oss-fuzz.com/v2/issue/4651449704251392/7004
2018-03-19 09:21:02 +01:00
fuzz-unit-file/oss-fuzz-7004
oss-fuzz: add the reproducer case by oss-fuzz #8064
2018-05-03 09:57:29 +02:00
fuzz-unit-file/oss-fuzz-8064
fuzz: add testcase for issue 8827
2018-06-11 05:39:59 +02:00
fuzz-unit-file/oss-fuzz-8827
test: add testcase for issue 10007 by oss-fuzz
2018-08-22 05:39:40 +02:00
fuzz-unit-file/oss-fuzz-10007
Hook up oss-fuzz test cases as tests This is a bit painful because a separate build of systemd is necessary. The tests are guarded by tests!=false and slow-tests==true. Running them is not slow, but compilation certainly is. If this proves unwieldy, we can add a separate option controlling those builds later. The build for each sanitizer has its own directory, and we build all fuzzer tests there, and then pull them out one-by-one by linking into the target position as necessary. It would be nicer to just build the desired fuzzer, but we need to build the whole nested build as one unit. [I also tried making systemd and nested meson subproject. This would work nicely, but meson does not allow that because the nested target names are the same as the outer project names. If that is ever fixed, that would be the way to go.] v2: - make sure things still work if memory sanitizer is not available v3: - switch to syntax which works with meson 0.42.1 found in Ubuntu
2018-01-19 07:54:30 +01:00
'''.split()