What does HackerNews think of syzkaller?

The key to modern fuzzing is feedback, usually some kind of coverage measurement of the program under test. This allows the fuzzer to be much smarter about how it finds new code paths and discards inputs that don't extend coverage. This makes fuzzing find bugs a lot quicker.

Google have a project to do fuzzing on Linux system calls using coverage feedback: https://github.com/google/syzkaller

Also see https://github.com/google/syzkaller - lots of kernel bugs found by this one

I'd start with reading the libfuzzer docs[0] and then read the syzkaller papers[1]

[0] https://llvm.org/docs/LibFuzzer.html [1] https://github.com/google/syzkaller

https://github.com/google/syzkaller

Syzkaller fuzzes that stuff. https://github.com/google/syzkaller

> Why does the Linux kernel project continue to release code with flaws like this that can be found with automated tools?

Because they have no other option, it's a fuzzer. Therefore, it may take a long time(up to universe heat death) for it to finally exercise the path that causes the issue. And the kernel has a pretty enormous footprint.

Fuzzers never really terminate, so it is not like you can plug it on a CI/CD system and wait for reports.

> The process of reproducing one crash may take from a few minutes up to an hour depending on whether the crash is easily reproducible or non-reproducible at all.

That's for one known crash. But otherwise it will be running 24/7 (across multiple VMs!) looking for issues.

More details here: https://github.com/google/syzkaller

Something like https://github.com/google/syzkaller?

A very common methodology is using a technique called fuzzing. There exists many fuzzers which have produced great success finding a plethora of both non-exploitable and exploitable bugs for Linux [1] [2].

[1] https://github.com/kernelslacker/trinity [2] https://github.com/google/syzkaller/

Some of the tools have been: https://github.com/google/syzkaller