4 ms·

code diff: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?h=for-next&id=e7ad651c31c5e1289323e6c680be6e582a593b26 https://git.ker

by BluSyn 4y ago

code diff: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?h=for-next&id=e7ad651c31c5e1289323e6c680be6e582a593b26 https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wir...

NickGerleman 4y ago
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 https://gcc.gnu.org/legacy-ml/gcc-help/2011-05/msg00360.html
- account42 4y ago
  > 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 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).
  - galangalalgol 4y ago
    Don't forget asan and ubsan. That requires good unit teat coverage to work though.
londons_explore 4y ago
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.
- UncleMeat 4y ago
  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.

by BluSyn 4y ago

NickGerleman 4y ago

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 https://gcc.gnu.org/legacy-ml/gcc-help/2011-05/msg00360.html

account42 4y ago
> 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 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).
- galangalalgol 4y ago
  Don't forget asan and ubsan. That requires good unit teat coverage to work though.

londons_explore 4y ago

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.

UncleMeat 4y ago
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.