| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without the size limits, oss-fuzz creates huge samples that time out. Usually
this is because some of our code has bad algorithmic complexity. For data like
configuration samples we don't need to care about this: non-rogue configs are
rarely more than a few items, and a bit of a slowdown with a few hundred items
is acceptable. This wouldn't be OK for processing of untrusted data though.
We need to set the limit in two ways: through .options and in the code. The
first because it nicely allows libFuzzer to avoid wasting time, and the second
because fuzzers like hongfuzz and afl don't support .options.
While at it, let's fix an off-by-one (65535 is the largest offset for a
power-of-two size, but we're checking the size here).
Co-authored-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
|
|
|
We have a few cases or reported issues which are about a timeout to parse
the input in 25 s. In all cases, the input is a few hundred kb. We don't really
care if the config parsers are super efficent, so let's set a limit on the input
size to avoid triggering such issues. The parsers often contain quadratic
algorithms. This is OK, because the numbers of elements are almost always very
small in real use. Rewriting the code to use more complicated data structures
to speed this up would not only complicate the code, but also pessimize behaviour
for the overwhelmingly common case of small samples. Note that in all those
cases, the input data is trusted. We care about memory correctness, and not
not so much about efficiency.
The size checks are done twice: using options for libfuzzer, and using an
internal check for afl. Those should be changed together. I didn't use a define,
because there is no easy mechanism to share the define between the two files.
|
