shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-11-07 01:27:11 +03:00
Code
491eecb376
systemd/test/fuzz-regressions/meson.build

31 lines
972 B
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 09:54:30 +03:00
# SPDX-License-Identifier: LGPL-2.1+
#
# Copyright 2018 Zbigniew Jędrzejewski-Szmek
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 16:27:04 +03: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 09:54:30 +03:00
fuzz_regression_tests = '''
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 16:27:04 +03:00
fuzz-dns-packet/oss-fuzz-5465
fuzz-dns-packet/issue-7888
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 16:31:24 +03: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 14:25:06 +03: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 14:51:08 +03:00
fuzz-unit-file/oss-fuzz-6886
core/service: fix memleak of USBFunctionStrings and USBFunctionDescriptors oss-fuzz #6892.
2018-03-15 13:42:00 +03: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 14:02:54 +03: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 17:43:35 +03:00
fuzz-unit-file/oss-fuzz-6908
fuzz-unit-file/oss-fuzz-6917
fuzz-unit-file/oss-fuzz-6977
basic/calendarspec: add check for repeat values that would overflow https://oss-fuzz.com/v2/issue/4651449704251392/7004
2018-03-19 11:21:02 +03:00
fuzz-unit-file/oss-fuzz-7004
oss-fuzz: add the reproducer case by oss-fuzz #8064
2018-05-03 10:57:29 +03:00
fuzz-unit-file/oss-fuzz-8064
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 09:54:30 +03:00
'''.split()
Copy Permalink