I'm surprised there were not compiler errors for unreachable code, in the cases where the code was returning directly before a goto.

Edit: Looks like GCC removed the warning because it was unreliable. Clang and MSVC seem to be in better shape. https://gcc.gnu.org/legacy-ml/gcc-help/2011-05/msg00360.html

> Edit: Looks like GCC removed the warning because it was unreliable. Clang and MSVC seem to be in better shape. https://gcc.gnu.org/legacy-ml/gcc-help/2011-05/msg00360.html

That is an odd position when -Wstringop-overflow also highly depends on the optimizer (and will frequently generate false positives!) but not only remains in GCC but is enabled by default (even without any -Wall/-Wextra).

Things like this are why its pays to compile your project with as many compilers as possible (as well as static analysis tools).

Don't forget asan and ubsan. That requires good unit teat coverage to work though.

Theres a lot of bugfixes there...

And some are obviously correct... But others would require a lot more understanding of the code to be sure they're correct.

Someone should go through this with a keen eye to check the fixes are actually correct, and aren't just making the fuzzer stop alerting while leaving a more subtle vulnerability open.

Yeah the fact that the kernel has changes like this with such minimal testing is the reason why we see regressions in these kinds of bugs all too often.