Using syzkaller, part 4: Driver fuzzing

[Posted June 26, 2020 by corbet]

Ricardo Cañuelo Navarro describes the challenges associated with fuzzing complex device drivers with Syzkaller — and some solutions. "V4L2, however, is only supported in the sense that the involved system calls (including the myriad V4L2 ioctls) and data structures are described. This is already useful and, equipped with those descriptions, Syzkaller has been able to find many V4L2 bugs. But the fuzzing process contains a lot of randomness and, while that's a good thing in many cases when it comes to fuzzing, due to the complexity of the V4L2 API, simply randomizing the system calls and its inputs may not be enough to reach most of the code in some drivers, especially in drivers with complicated interfaces such as those based on the Request API, including stateless drivers."

Using syzkaller, part 4: Driver fuzzing

Posted Jun 26, 2020 19:17 UTC (Fri) by deater (subscriber, #11746) [Link] (1 responses)

I get this a lot too. "why use perf_fuzzer when syzkaller exists?"

perf_fuzzer finds bugs that syzkaller doesn't, in part because by being aware of how the syscall works you can focus the (enormous) search space to combinations of inputs more likely to trigger errors.

Using syzkaller, part 4: Driver fuzzing

Posted Jun 27, 2020 15:10 UTC (Sat) by Paf (subscriber, #91811) [Link]

It also seems especially important to have different families/types of fuzzers - they will walk the (extremely broad) parameter spaces in different ways, finding (ideally) different types of issue. This seems especially important for fuzzing suites, whereas the benefit of having two different (for example) POSIX correctness suites seems likely to be less. (Not that the benefit of that would be zero)