Kernel bugs hide for 2 years on average. Some hide for 20

Post by woliveirajr » Thu, Jan 08, 2026, 12:32 PM UTC

ValdikSS wrote: post #55

grsecurity project has fixed many security bugs but did not contribute back, as they're profiting from selling the patchset. It's not uncommon for the bugs they found to be rediscovered 6-7 years later. https://xcancel.com/spendergrsec

Post by staticassertion » Thu, Jan 08, 2026, 12:40 PM UTC

rjzzleep wrote: post #46

aw1621107 wrote: post #39

Earlier quoted context omitted.

> are the state machine race conditions logic races (which Rust won’t trivially solve) or data races? If they are data races, are they the kind of ones that Rust will catch (missing atomics/synchronization) or the ones it won’t (bad atomic orderings, etc.). The example given looks like a generalized example: spin_lock(&lock); if (state == READY) { spin_unlock(&lock); // window here where another thread can change sta…

I'd argue, that while null ref and those classes of bugs may decrease, logic errors will increase. Rust is not an extraordinary readable language in my opinion, especially in the kernel where the kernel has its own data structures. IMHO Apple did it right in their kernel stack, they have a restricted subset of C++ that you can write drivers with. Which is also why in my opinion Zig is much more suitable, because it a…

Post by staticassertion » Thu, Jan 08, 2026, 12:43 PM UTC

giamma wrote: post #81

Is the intention of the author to use the number of years bugs stay "hidden" as a metric of the quality of the kernel codebase or of the performance of the maintainers? I am asking because at some point the articles says "We're getting faster". IMHO a fact that a bug hides for years can also be indication that such bug had low severity/low priority and therefore that the overall quality is very good. Unless the time…

Post by jiggawatts » Thu, Jan 08, 2026, 12:47 PM UTC

aw1621107 wrote: post #39

johncolanduoni wrote: post #35

Earlier quoted context omitted.

It depends what they mean by some of these: are the state machine race conditions logic races (which Rust won’t trivially solve) or data races? If they are data races, are they the kind of ones that Rust will catch (missing atomics/synchronization) or the ones it won’t (bad atomic orderings, etc.). It’s also worth noting that Rust doesn’t prevent integer overflow, and it doesn’t panic on it by default in release buil…

> are the state machine race conditions logic races (which Rust won’t trivially solve) or data races? If they are data races, are they the kind of ones that Rust will catch (missing atomics/synchronization) or the ones it won’t (bad atomic orderings, etc.). The example given looks like a generalized example: spin_lock(&lock); if (state == READY) { spin_unlock(&lock); // window here where another thread can change sta…

Post by a3w » Thu, Jan 08, 2026, 1:15 PM UTC

dpc_01234 wrote: post #41

Might be obviously, but there is definitely a lot of biases in the data here. It's unavoidable. E.g. many bugs will not be detected, but they will be removed when the code is rewritten. So code that is refactored more often will have lower age of fixed bugs. Components/subsystems that are heavily used will detect bugs faster. Some subsystems by their very nature can tolerate bugs more, while some by necessity will ne…