Linux 7.3-rc1 shipped this week, opening the roughly seven-week testing window before the stable release lands — pencilled in for 18 October, or a week later if things get messy. Greg Kroah-Hartman, the kernel's second-in-command, is already warning it probably will.
The reason isn't a difficult feature or a contentious redesign. It's volume. Kroah-Hartman shared a look at his own inbox for the USB subsystem he maintains: thousands of pending messages, the backlog barely shrinking even after a pass through the obvious fixes. Much of it, he said, traces back to static-analysis tooling surfacing old, minor issues that only show up if a driver is used in some unusual way nobody actually does in practice.
That doesn't make the flood easy to ignore. Buried in the noise are genuine bugs, and Kroah-Hartman has been clear that rejecting anything that looks like a real fix isn't something he's willing to do just to save time — so the pile gets worked through by hand, patch by patch.
A pattern, not a one-off
This is the third or fourth kernel cycle in a row where AI-generated activity has visibly shaped the maintainers' workload. The number of CVEs fixed per release has climbed from a historical average around 500 toward nearly 2,000, a jump largely credited to language models combing through decades of C code few humans had reread recently. Old, rarely-used hardware drivers are being retired faster than before, partly just to shrink the surface these tools keep finding things in.
The kernel's staging area — traditionally a soft landing spot for newcomers' first patches — went further back in August: it now rejects AI/LLM-authored submissions outright, with one exception carved out for genuine security fixes.
None of this changes what Linux 7.3 will look like on a running desktop or server. But it's a fairly clear sign that the day-to-day work of maintaining the kernel is being reshaped by the same tools everyone else is finding uses for — for better and for messier.
Source: Phoronix