AI Is Finding Thousands of Old Vulnerabilities in the Linux Kernel

The number of known vulnerabilities in the Linux kernel has surged, and the reason isn't worse code: it's AI tools scanning parts of the kernel that no one had reviewed in years. According to a report from Tom's Hardware cited by CNews, the total number of recorded flaws jumped from around 500 a few years ago to nearly 2,000, and the curve keeps rising release after release.

The Numbers, Version by Version

The source compares different kernel builds to show the pace. What stands out is the acceleration in the final months of 2026, when the community's use of AI analyzers became routine.

| Version | Date | Known vulnerabilities | |---|---|---| | Linux 6.0 | Oct 2, 2022 | ~500 | | Linux 7.0 | Apr 12, 2026 | ~1,000 | | Linux 7.2 | Aug 16, 2026 | ~1,500 | | Linux 7.3 (expected) | — | could top 2,000 |

In four months, between 7.0 and 7.2, the number of known flaws grew 50%. The forecast from experts interviewed by Tom's Hardware is that 7.3 will surpass the 2,000 mark.

Why Now, and Not Before

The central point of the report: this growth does not mean the kernel has become less secure or that developers have gotten sloppy. The cause is a combination of two factors.

First, the size and age of the codebase. In 2026 the kernel turned 35 years old and passed 40 million lines, written by dozens of programmers over decades. Second, the ability of AI tools to scan millions of lines in a short time, including sections no one had touched in years, exactly where flaws tend to hide.

In other words: the vulnerabilities were always there. Human review simply never went back to the dusty corners of the kernel, and AI does.

We are completely overwhelmed.

>

-- Jakub Kicinski, Linux kernel maintainer

The Noise: Not Everything Is a Critical Flaw

Before any panic about machines running in production, the source is explicit: a good portion of the flaws found are low priority. Many appear in rarely used driver code, and some are simply AI hallucinations, meaning findings that don't correspond to real vulnerabilities.

This creates a new task for the community: separating genuine, potentially dangerous flaws from the noise generated by the scanners. In the Linux 7.3 kernel, currently in preparation, between a third and half of the 648 proposed patches are low-priority fixes, adjustments, or refinements originating from AI. Hence Kicinski's remark about being overwhelmed: the volume of automated suggestions is eating up maintainers' time.

The Discussion This Reopened: Killing Off Old Drivers

The most interesting side effect for anyone thinking about architecture is political-technical. With AI flagging flaw after flaw in old drivers, the community has started questioning whether it's worth keeping legacy code that almost no one uses.

In April 2026, developer Andrew Lunn proposed removing nearly 28,000 lines of legacy networking code, covering ISA and PCMCIA-era hardware, interfaces popular in the 1990s and early 2000s and now practically extinct. The reasoning: historically these drivers required minimal attention because almost no one used them, but now the flaws flagged by AI force fixes regardless, eating up maintainers' time whether or not there are real users.

Kernel 7.3 is expected to drop old SGI and IBM drivers, along with other obsolete components. It's a cost-benefit reassessment: does compatibility with old hardware justify the effort of keeping that codebase alive and flaw-free?

What Changes for Anyone Running Linux in Production

Readers who maintain services on Linux need to read this growth in numbers calmly, not as a sign that the platform has turned into Swiss cheese. Some practical points that emerge from the scenario described by the source:

• A higher CVE count doesn't mean more risk. A spike in the total number of known flaws reflects greater scrutiny, not degradation. Reading vulnerability-count headlines without looking at severity and attack surface leads to the wrong decision.
• Prioritization becomes the job. If half of a release's patches are low-priority noise, anyone managing internal patching will feel the same problem on a smaller scale: more warnings to triage. It's worth tracking severity and the affected subsystem, not the raw count.
• Legacy drivers tend to disappear. Anyone who depends on old hardware or niche drivers should keep an eye on changelogs. The removal of ISA/PCMCIA code and SGI/IBM drivers is a warning sign: keeping a new kernel running with old peripherals may stop being possible.
• The surface that matters is the one you actually use. A flaw in a driver you don't load doesn't affect your machine. Reducing the surface (lean kernel, unnecessary modules stripped out) remains the best defense, now backed by statistics on what AI is finding.

In practice, the takeaway here is that AI has transformed the kernel auditing process, but shifted the bottleneck to human judgment: someone still has to decide what's real, what's urgent, and what's dead code that should be removed. That triage work, not the flaw count, is what will define the kernel's practical security in upcoming releases.