blob: 3342f01e4efbbbdac02d02a97de902bbbc8dc874 [file] [log] [blame] [view]
# Fuzzing
Wuffs has been fuzzed (on [OSS-Fuzz](https://google.github.io/oss-fuzz/)) since
[February
2018](https://github.com/google/oss-fuzz/commit/27f374480b1e7c780d161b7a6727c23cc03419c5).
As of November 2019, this has not yet found any memory-safety bugs in Wuffs.
Compile-time safety checks seem to work.
However, it has found a few correctness bugs, based on generating random input.
Wuffs' fuzzer programs will [intentionally
segfault](https://github.com/google/wuffs/blob/7ec252876541ec203659949450fafddc148b606e/fuzz/c/fuzzlib/fuzzlib.c#L61)
if the Wuffs library returns an "internal" error message.
For example, Wuffs [won't let you write `x -=
1`](/doc/note/interval-arithmetic.md#i--i--1-doesnt-compile) unless you can
prove that it won't underflow. The programmer might 'know' that `x` is always
positive at some point in their program, but to satisfy Wuffs' [bounds
checker](/doc/note/bounds-checking.md), they have to explicitly write something
like:
```
if x > 0 {
x -= 1
} else {
// Unreachable: x is always positive because blah blah blah.
return "#internal error: etc"
}
```
Hitting the else branch means that there's a bug: what the programmer 'knew'
was incorrect. These aren't security bugs per se: decoding an image would
produce the wrong pixels, or abort early, instead of leading to RCE (Remote
Code Execution). But fuzzing Wuffs has still been useful.