Re: Talk proposal: What 125K kernel bugs tell us about testing gaps

On Wed, Feb 04, 2026 at 06:49:57PM -0800, Jenny Qu wrote:
> Hi,
> 
> I'm a security researcher working on automated kernel vulnerability
> detection. I'd love to present at an upcoming Thursday call if there's
> interest.

Cool, but isn't this a better subject for a conference talk?

> I analyzed every Fixes: tag in the kernel's 20-year git history (125K
> bug-fix pairs) and built a model to catch vulnerabilities at commit
> time. Some findings that might be relevant to KernelCI's testing
> strategy:
> 
> - Security bugs hide for 2.1 years on average; race conditions persist 5.0 years
> - 117 "super-reviewers" (including Dan Carpenter, who invented the
> Fixes: tag) catch bugs 47% faster
> - Subsystems like CAN bus (4.2 years) and SCTP (4.0 years) have
> dramatically longer bug lifetimes than gpu/i915 (1.4 years)
> - Weekend commits are 8% less likely to introduce bugs, but take 45%
> longer to fix (review coverage effect)
> 
> The model (VulnBERT) achieves 92% recall at 1.2% false positive rate
> on held-out 2024 data. I'm also working on SmartKuang, an RL-based
> system that has reproduced CVE-2022-34918 autonomously.

I hate to say "your ai model could be replaced with a sql statement",
but really, we do have tools that show this today that give all of this
data in a sqlite database that people can use to mine for the same info.
It's what the kernel CVE team uses to track bug fixes over time for
their work:
	https://git.sr.ht/~gregkh/verhaal
and is part of the vulns.git repo on git.kernel.org

Also for the tracking of employer to people and who is doing the work,
see the reports on lwn.net for the past few decades that have been
documenting this.  The tool for that is also public (but part of the
database of employer mapping is not for obvious reasons, sorry).  I
think you undercounted people's employers a lot as you can not always
rely on email addresses to convey this.

Anyway, I liked your reports as I'm always interested in more people
mining our public data for stuff like this, it's great to see.  But with
regards to kernelci, how do you feel this information can help with our
project?  What would you like us to do based on what you have found
here?

thanks,

greg k-h