On Thu, May 16, 2024 at 12:48:47PM -0700, Justin Stitt wrote: > I don't think we're capable of identifying every single problematic > overflow/wraparound case in the kernel, this is pretty obvious > considering we've had decades to do so. Instead, it seems much more > feasible that we annotate (very, very minimally so as not to disrupt > code readability and style) the spots where we _know_ overflow should > happen.
For the baby steps Linus wants, we can walk this path: - Finish the *signed* integer overflow refactoring/annotation. This is nearly done already, and every case we've found is either a legitimate bug (thankfully rare), or happens in code that is either accidentally correct (thanks to no UB), or the correctness is very unclear. Refactoring these cases improves readability for everyone and doesn't change the behavior. - Begin *signed* integer implicit truncation refactoring/annotation. As Linus suggested, dealing with this will catch a bunch of the flaws we've seen recently. Handling the false positives here will need some investigation and some compiler support, and that'll happen in parallel. - Tackle *unsigned* integer overflow on a per-type basis: we can start with the place Linus called out: size_t. This will let us focus on the first of the unsigned types that is not commonly wrapping, and is a regular place that unexpected overflow gets the kernel into big trouble. What we learn from these three steps should inform us what further steps down this path can look like. -Kees -- Kees Cook
