Greg Kroah-Hartman sees a rough Linux 7.3 cycle under an AI patch flood

September 2, 2026. Greg Kroah-Hartman, the number-two maintainer of the Linux kernel, warns on social.kernel.org that 7.3 is “going to be a rough -rc cycle.” 1,732 messages. That is the size of his “todo” queue for the USB subsystem alone — cut to 1,094 after a first pass on the obvious fixes. October 18, 2026. The target date for the Linux 7.3 stable release, pushed to October 25 if the tail of the cycle turns ugly. Why it matters: the kernel’s bottleneck is no longer code — it is human review capacity in the face of a flood of AI-produced patches.

An inbox that is overflowing

The signal is numeric, and it is brutal. Greg Kroah-Hartman shows his todo mbox for linux-usb: [Msgs:1732/4807 Inc:2 78M]. After a first pass over the “easy” patches — the ones that obviously fix a bug, or an older version superseded by a newer submission — what remains is [Msgs:1094/4170 Inc:2 69M]. “Still crazy though,” he notes.

The cause is named: kernel developers are being bombarded by AI-generated bug-fix patches, “some genuine while others not so useful,” often touching code that has been inactive for years or drivers that are obsolete. A “huge majority” of current submissions come from static analysis tooling that finds “really old minor things that can be triggered if you ’hold it wrong’.”

What stands out is the maintainer’s caution. He regularly “pushes back” against AI submissions, but refuses to blanket-deny what is “obviously a bugfix.” “Refusing ’obviously a bugfix’ is hard, and I don’t want to do that — it will just take time to grind through them all.” His conclusion reads like a warning: “Like I’ve been saying for the past few months in talks, ’It’s going to be a long 18 months,’ and somehow that number doesn’t seem to get shorter.”

The real bottleneck is no longer code

What is changing is the nature of the maintenance job itself. Historically, the limit on a development cycle was producing fixes: few people wrote code for aging drivers. Today, the limit is review. A machine produces code faster than a human can judge it, and every AI patch demands a verification that a human author would have provided while writing it.

The kernel has already responded where it can. For the staging tree, which Greg Kroah-Hartman also oversees, a policy rejects AI patches except for real security fixes. Elsewhere the response is more artisanal: triage, push back, accept the obvious, and absorb the time cost. The result is a 7.3 cycle that starts heavy while barely into its -rc phase.

Nearly 2,000 CVEs per release

The patch flood has a direct translation into security numbers. Previewing his Kernel Recipes 2026 talk (Paris, September 21–23), Greg Kroah-Hartman showed the count of CVEs fixed per release. From Linux 6.9 through 6.19, the kernel hovered around 500 CVEs per release. Since Linux 7.0 it has been above one thousand; 7.2 broke 1,500, and 7.3 could push past 2,000.

The nuance is essential, and Phoronix underlines it: most of these CVEs are low severity, often sitting in old or obscure drivers — “the impact is often minimal.” With the kernel source approaching 40 million lines — 7.3-rc1 weighs in at 40.98 million lines, 560,000 more than 7.2 — the reservoir of potential flaws that LLMs can flag is enormous.

The takeaway is not that the kernel is becoming more dangerous, but that the CVE signal is diluting. When a release fixes 2,000 entries whose majority are unexploitable in practice, separating the real emergencies becomes a job in itself.

What it changes for kernel consumers

For a distribution, the equation is familiar: backport security fixes into its stable kernels without importing the noise. The inflation of CVEs makes that triage more expensive, not simpler. For an infrastructure team, the consequence runs against intuition: it becomes less rewarding to chase every reported kernel CVE, and more rewarding to lean on the stable and LTS trains that maintainers keep updated.

The good practice does not change, but it gets more demanding. Update the kernel continuously, prefer stable/LTS versions, and prioritize CVEs with high CVSS scores or active exploitation. The rest — the hundreds of minor defects in drivers nobody uses — resolves through regular updates, not through an individual chase.

What 7.3 actually contains, under the noise

Beneath the patch churn, 7.3 does carry real features: initial AMD Zen 6 support, Btrfs optimizations, and the 2026 Steam Controller, to name only what Phoronix flagged when 7.3-rc1 shipped. The size of the cycle — 560,000 lines added, on a tree of 40.98 million — is both a promise of features and a reservoir of additional bugs to triage.

This is where the mechanics turn circular: the bigger the kernel grows, the more defects static tools find, the more the fix stream swells, the slower review becomes. Greg Kroah-Hartman summed it up in one image: his todo mbox never empties. The long-term answer is not more maintainers — you cannot conjure those — but stricter triage policies, like the one already applied to the staging tree.

Who is sounding this alarm

Context matters for weighing the warning. Greg Kroah-Hartman is not just another contributor: he maintains the stable branches, oversees the USB subsystem and the staging tree, and carries an outsized share of the daily review load. When he calls a cycle “rough,” it is not a blogger’s opinion — it is the diagnosis of the man who literally triages thousands of messages per cycle.

That concentration of load is itself a risk. The day the human bottleneck gives way, it is not one driver that suffers but the security-patch cadence of the whole ecosystem. That is why the AI patch flood is not hallway gossip: it bears on the sustainability of the kernel’s entire maintenance model.

One yardstick makes the point concrete: a distribution that tried to backport every one of those 2,000 fixes would spend its whole release window on security, leaving no room for features. That is why the stable and LTS trains, where maintainers pre-sort the noise, have quietly become the actual product.

Verdict

If you maintain a kernel or a distribution, plan ahead: the 7.3 cycle will be long, the stable release will land between October 18 and 25, and the CVE volume will keep climbing. Invest in automated triage of the CVE stream rather than manual review of each one.

If you run servers, stay on the stable and LTS trains, update continuously, and treat only the genuinely exploitable or high-CVSS CVEs individually. The noise of 2,000 CVEs should not dictate your cadence.

In every case, Kroah-Hartman’s warning is an ecosystem signal: human review has become the kernel’s scarce resource. One more patch is no longer a contribution — it is a review cost.

References

• Phoronix — Greg KH Forewarns Of “Rough” Linux 7.3 Kernel Cycle Due To Continued AI Churn, September 2, 2026
• Phoronix — The Linux Kernel Is Approaching 2,000 CVEs Per Release, August 28, 2026
• Phoronix — Linux 7.3-rc1 With AMD Zen 6 Additions, Better Btrfs Performance, August 30, 2026
• Phoronix — Linux 7.3-rc1 Close To 41 Million Lines, September 1, 2026
• Kernel Recipes 2026 — Paris, September 21–23, 2026