TL;DR
An analysis of Fixes: tags in the Linux kernel's git history (2005–2025) found that bugs live about 2.1 years on average, with a few surviving two decades. The researcher mined 125,183 tagged bug-fix pairs, showed faster discovery rates for recent bugs, and demonstrated an ML tool that catches a large fraction of historical fixes at commit time.
What happened
A researcher mined the Linux kernel's git history for commits that include a Fixes: tag and assembled 125,183 traceable bug–fix pairs spanning 2005–2025. After filtering, the full dataset shows an average bug lifetime of about 2.1 years and a median lifetime of 0.7 years; the longest-lived entry in the collection was a 20.7-year-old buffer overflow. Initial sampling of recent (2025-only) fixes produced higher average lifetimes because that subset included many ancient bugs that were finally being discovered. The full-history view shows improving speed: the share of bugs found within one year rose from near zero for 2010-introduced bugs to roughly 69% for bugs introduced in 2022, though the author cautions that recent-year figures are right-censored. Subsystem and bug-type analyses reveal wide variation: some networking areas and race conditions persist far longer, while BPF and GPU issues tend to be found sooner. The author also built an ML model that recovers most historical fixes at commit time with a low false-positive rate.
Why it matters
- Bugs that linger for years can accumulate operational and security risk, especially in core subsystems used by many deployments.
- Faster detection of recent bugs suggests improvements in testing and tooling are having measurable effects.
- Certain subsystems and bug classes (e.g., race conditions, niche protocols) remain hard to exercise and diagnose.
- Incomplete tagging and inconsistent root-cause tracing limit how fully we can measure and address historical defects.
Key facts
- Dataset: 125,183 Fixes: tagged bug–fix records mined from Linux git history (2005–2025).
- After filtering, the full-history average bug lifetime was about 2.1 years; median 0.7 years.
- Longest-lived bug in the dataset: a 20.7-year-old buffer overflow.
- Percentage found within one year increased from ~0% for 2010 to ~69% for 2022 (right-censoring applies).
- Some subsystems show much longer averages: drivers/can 4.2 years, SCTP networking 4.0 years; networking overall 2.9 years.
- Bug types with longest averages: race conditions ~5.1 years; integer overflow ~3.9 years; use-after-free ~3.2 years.
- A detailed case involved a refcount leak in netfilter that persisted ~19 years due to a missing 'ct != last' check after an earlier fix.
- Coverage note: the kernel contains ~448,000 commits that mention 'fix' but only ~124,000 (≈28%) use a proper Fixes: tag; the dataset captures well-documented tracebacks.
- The author built a classifier (VulnBERT) achieving 92.2% recall on a held-out 2024 test set with a reported 1.2% false-positive rate.
What to watch next
- Wider adoption of targeted fuzzers and sanitizers (Syzkaller, KASAN/KMSAN/KCSAN) and improved static analysis, which the author credits with speeding discoveries.
- Efforts to increase consistent use of Fixes: tags and root-cause tracing to improve future measurement and triage.
- Continued tracking of the fraction of bugs found within one year as a metric for progress, while accounting for right-censoring in recent years.
Quick glossary
- Fixes: tag: A commit message convention in the Linux kernel where a fixing commit references the commit that introduced the bug, allowing traceability from fix to introduction.
- Fuzzing (Syzkaller): Automated testing that feeds generated inputs to software to find crashes and bugs; Syzkaller is a syscall fuzzer commonly used on Linux kernels.
- Race condition: A class of defect that appears under specific timing or ordering of concurrent operations, often intermittent and hard to reproduce.
- Refcount leak: When a reference-counted object has its count incremented without a matching decrement, preventing its memory from being freed.
- Right-censoring: A statistical issue where recent events cannot yet reach their eventual lifetime, biasing short-term averages downward.
Reader FAQ
How many kernel bugs were analyzed?
The miner collected 125,183 Fixes: tagged records across 2005–2025; the author applied filtering for analysis.
Does this cover all kernel bugs?
No. The study only includes fixes that include a proper Fixes: tag; the author notes roughly 28% of commits mentioning 'fix' use such tags.
Are recent bugs getting found faster?
Yes: the share discovered within one year rose from near 0% for 2010-introduced bugs to about 69% for 2022-introduced bugs, but recent-year measures are right-censored.
Did the researcher build tooling to detect bugs automatically?
Yes. The author reports a model that recovered 92.2% of historical bugs on a held-out 2024 test set with a 1.2% false-positive rate.
Does the report assess downstream security impact?
not confirmed in the source
Kernel bugs hide for 2 years on average. Some hide for 20. January 7, 2026 • by Jenny Guanni Qu (jenny@pebblebed.com) There are bugs in your kernel right now that…
Sources
- Kernel bugs hide for 2 years on average. Some hide for 20
- Serious Security: The Linux kernel bugs that surfaced after …
- An In-depth Analysis of Duplicated Linux Kernel Bug Reports
- Uncovering a 24-year-old bug in the Linux Kernel (2021)
Related posts
- Google and Character.AI Negotiate Major Settlements in Teen Chatbot Death Cases
- Don’t Let the Grocery Store Scan Your Face — How to Resist Wegmans’ Plans
- Why Email Encryption Fails in 2026 — Lessons from gpg.fail and DKIM