Interesting that Google's syzbot found and publicized the flaw, possibly bringing it the awareness of bad actors. But at the time the flaw was not flagged as being security related and was thus not backported as a security patch.
If Google's syzbot had checked the kernel for the flaw before it was released instead of after, that also seems like it would have prevented the issue from going live in the first place.
Why does the Linux kernel project continue to release code with flaws like this that can be found with automated tools?
> 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.
Depending on what was meant by "like this", they do have the option of fixing this class of bugs (memory safety vulns), using mature tried and tested programming language practices and technology. It's a decades old debate between the C enthusiasts and the correctness/security enthusiasts. (Same problems and options are of course available Apple and Microsoft - it's not just Linux)
Well, Rust is not that mature, I agree today it would be an option worth considering. But people have been writing ring-0 code in safe languages for decades. And of course there are more dimensions to robust kernel design than chocie of programming language.
It finds memory safety bugs, so it would be prudent to treat all findings as security bugs by default. The binder driver maintainers did get notified right away and it's a prominent part of android attack surface.
If Google's syzbot had checked the kernel for the flaw before it was released instead of after, that also seems like it would have prevented the issue from going live in the first place.
Why does the Linux kernel project continue to release code with flaws like this that can be found with automated tools?