linux A field note by Vikrant Sharma
Linux kernel CVE flood is breaking security triage
The kernel security team is drowning in CVEs. Most are low severity, many are duplicates, and the noise is making it harder to catch the real threats.
The Linux kernel security team is getting buried in CVE reports. Not because attackers suddenly got better at finding bugs. Because automated tools got better at filing them. The problem is volume. Hundreds of kernel CVEs land every quarter now. Most are low severity use-after-free bugs that need root access to trigger. Many are duplicates of the same underlying issue, each fork of the kernel tree gets its own CVE. The signal-to-noise ratio is collapsing. What caught my attention is how this breaks the triage process. Security engineers at companies running Linux cannot manually review every CVE anymore. They automate it, which means they miss context. A CVE marked critical might be unexploitable in practice. A CVE marked low might combine with something else to become serious. The metadata is not good enough to script around. The kernel team’s proposed fix is interesting. They want CVE reporters to include a severity score that actually reflects exploitability, not just theoretical impact. They want automated tools to check for duplicates before filing. They want distributions to share triage notes so everyone is not doing the same analysis in parallel. None of this solves the root issue, which is that the CVE system was designed for user-space application bugs and does not scale to a 30 million line kernel with a thousand contributors. The kernel gets patched faster than most CVEs get assigned. By the time a CVE lands, the fix is already in stable. What I would change if I was running detection: stop treating CVEs as gospel. Parse them, sure, but cross-check against kernel mailing list patches and LKML discussions. The real signal is in what maintainers are backporting to stable branches, not what got a CVE number three weeks later.