Linux 7.3-rc2 Comes In Full Fat After Late Pulls

Linux 7.3-rc2 arrived on September 6, and Linus Torvalds called it a full fat release at the quietest point in the cycle. rc2 is usually the breather after the merge window, when bug reports have not started in volume yet. This one still packed filesystem fixes, a sizable DRM pull, networking and BPF work, plus a run of driver trees.

He said nothing in the diff looked particularly odd. Then he offered the line every rewrite would print: everyone would blame AI, whether that was the cause or not.

Torvalds Called It Full Fat and Named the Piles

In his Sunday Linux 7.3-rc2 announcement, Torvalds wrote that the week “didn’t *feel* like a particularly busy rc2, but it clearly was.” He reached first for a late Error Detection and Correction pull that missed the merge window, then waved that aside as a fairly small thing.

The rest of the list was ordinary kernel weather that happened to arrive at once. Several filesystems sent fixes. The graphics tree sent a fairly sizable DRM pull of scattered repairs. Networking and BPF sent more. A number of driver trees piled on top.

THE PILES TORVALDS NAMED

• Late EDAC: A forgotten merge-window pull he called too small to explain the week.
• Filesystems: Several trees sent fixes in the same rc2 window.
• DRM: A fairly sizable graphics pull of scattered repairs.
• Networking and BPF: Both sent fixes alongside the rest.
• Driver trees: Several landed in the same quiet week.
• Tooling: About 20% of the whole patch, mostly sched_ext and selftests.

Outside drivers, which he said always dominate, tooling was the biggest slice, then filesystems, core kernel, and networking. That 20% figure is for the entire patch, not a remainder after drivers are removed.

It might be just random, but we’ll obviously all blame it on AI, because whether that’s really the cause or not, it’s an easy thing to blame;)

Linus Torvalds, Linux 7.3-rc2 announcement, LKML

The wink is doing work the shortlog does not. He never pointed at a counted set of machine-written commits. He pointed at trees that missed or stacked, then reached for the joke because it is handy.

The USB Maintainer’s 1,732 Unread Messages

The joke lands because the people who review those trees are already behind. Greg Kroah-Hartman, who maintains USB and the stable kernels, warned on September 2 that this would be a rough -rc cycle, even for old subsystems that should be quiet.

His filtered USB todo mailbox showed 1,732 USB messages in his todo mailbox out of 4,807, a 78M folder. After a first pass on the easy ones, obvious bugfixes or older copies replaced by newer mail, he was still looking at 1,094 of 4,170 and a 69M folder. That first cut cleared 638 of the filtered USB notes and dropped 637 messages from the wider pile. He still called it crazy.

GREG KH’S USB TODO

• First snapshot: 1,732 of 4,807 messages, 78M, filtered for linux-usb.
• After easy cuts: 1,094 of 4,170 messages, 69M.
• His forecast: A rough -rc cycle, and “a long 18 months” that does not get shorter.

He said he pushes back often on AI-generated submissions. Refusing a patch that is “obviously a bugfix” is hard, and he does not want to do that, so the grind continues. For staging, he already bars LLM patches except real security fixes.

I push back a lot, but refusing “obviously a bugfix” is hard, and I don’t want to do that, it will just take time to grind through them all. 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….

Greg Kroah-Hartman, social.kernel.org, September 2, 2026

A huge majority of the current USB pile, he said, comes from static analysis that finds really old minor things you can trigger if you “hold it wrong.” Those still count as vulnerabilities at kernel level. Syzbot also went one layer deeper on USB gadget and device code, which he treated as normal fuzzer work rather than LLM noise.

The cost is time, not a fatter tarball by itself. Pushing back on a bad patch can take longer than writing the fix, and a real bugfix still has to be read.

A Third of Net-Next Looked Like Cleanup

Linux networking maintainer Jakub Kicinski put numbers on the same squeeze in the 7.3 networking pull. He and Paolo Abeni merged 632 patches in net, the fixes tree, and 648 in net-next, the feature tree. Those two streams are not supposed to move at the same speed.

Quick and dirty count suggests we (Paolo and I) merged a very similar number of net (632) and net-next (648) patches. This is not telling the full story either because 1/3 to 1/2 of the net-next patches also *seem* like AI-driven low priority fixes, cleanups and clarifications.

Jakub Kicinski, Linux 7.3 networking pull request

He wrote that the team was completely overwhelmed. A plausible null check is cheap to emit and expensive to trust. The networking group has been paying for extra model passes on incoming patches, with budget Kicinski said Meta helped cover, because reading the mail still falls on people.

That is the layer the rc2 joke sits on. A quiet week that is not quiet is easier to laugh at than a maintainer reading the 400th cleanup against code nobody uses. The public argument around the wink treated it as a new homework excuse. The mailing-list post above that line is a list of subsystem pulls, not a census of chatbots.

What Landed in Linux 7.3-rc2

The second candidate is a bag of real fixes, not a vibe. Networking got targeted TCP and IPv6 work, including use-after-free repairs in TCP_CONGESTION and TCP_CC_INFO socket options from Cen Zhang at Microsoft Security FORGE Labs. The ksmbd SMB server picked up memory-safety patches, among them an oplock-break use-after-free and tree-connect lifetime bugs. NTFS and XFS both sent adjustments, with NTFS covering readdir, xattr, and cluster-accounting paths.

FIXES INSIDE 7.3-RC2

Nouveau developer Mohamed Ahmed described four independent groups of GPU System Processor display bugs found while bringing up HDMI 2.1. The set covers HDMI vendor infoframes on GB20x, HDMI GCP AVMute register offsets, and vblank interrupts on Blackwell cards. Some of it is not a user-facing break yet. He pointed at a 2.147GHz pixel clock cap that still has to move before FRL, DSC, and VRR work correctly.

Kees Cook, who leads a lot of kernel hardening, ran another tree-wide pass that moves more kmalloc() call sites to the newer kmalloc_obj() family across hundreds of files. A separate change turns the RandStruct security feature off by default when a usable Rust compiler toolchain is present, to avoid a circular dependency between RandStruct and Rust kernel support.

The forgotten EDAC updates for 7.3 did land in this window, pulled by Borislav Petkov. They add Intel Starfire SoC support in the iGEN6 driver, load AMD’s address translation library only on machines with ECC memory, orphan the ThunderX and MPC85XX EDAC drivers, and drop a fake error-injection debugfs path. Torvalds was right that this block is not the whole story. It is one named late piece among several.

40.98 Million Lines Before the Quiet Week Even Started

The cycle was already large before rc2. Torvalds tagged 7.3-rc1 on August 30 and said nothing really stood out except that it was big, at least in commit count. The fat diff, he said, was another AMD GPU register dump. This time the DCN6 headers, plus code for the new generation, accounted for about a third of the whole rc1 patch.

CLOC ON THE 7.3-RC1 TREE

That is about 560,000 added lines from 7.2 to 7.3-rc1. The AMD directory alone grew by about 170,000. Strip the register headers and Torvalds said the rest of the merge window looked pretty normal. He also called himself a grade A nincompoop for doing a system upgrade mid-window, then said that mess was cleaned up.

Stable maintainer slides teasing Kernel Recipes 2026, set for September 21 to 23 in Paris, showed CVE counts jumping above 1,000 with Linux 7.0 and above 1,500 with Linux 7.2, against about 500 through much of the 6.x era. If that path holds, 7.3 could pass 2,000. That is a count of tagged findings, many of them in obscure drivers, not a claim that the kernel suddenly got twice as unsafe.

Contributors Already Have to Tag Machine Help

The project already has a way to mark machine-assisted work. Kernel docs tell AI tools and the people driving them to follow the normal development process, keep the code GPL-2.0-only, and never let an agent add a Signed-off-by. Only a human can certify the Developer Certificate of Origin. That person has to review the output, own the license, and take the blame.

Contributions should carry an Assisted-by tag in commit messages in the form Assisted-by: LLM, with optional extra tools such as coccinelle or sparse. Basic editors and compilers stay off that line. If an assistant finds a bug, the same docs say it must try to write a fix, build it, and say so when a reproducer was never made, because maintainers waste too much time on unverified reports.

THE ASSISTED-BY RULES

• The tag: Assisted-by: LLM, plus optional analysis tools, not git or gcc.
• Signed-off-by: Humans only. An agent must not certify the DCO.
• Unverified reports: Say so if the fix was not built or no reproducer exists.
• Maintainer choice: Extra scrutiny, a lower queue, extra tests, or a straight reject.

Separate guidelines on tool-generated content say a chatbot function, a generated changelog, or a.c file cleaned up after an assistant all sit in scope. Maintainers may treat that mail like any other patch, or they may not. Torvalds did not cite an Assisted-by tally when he called rc2 full fat. The instrument exists. The rc2 note does not use it.

That gap is why the wink travels. In July he told the lists Linux is not an anti-AI project and that people who hate the tools can fork or walk away. In August he used a model as grunt labor on an Intel Xe graphics bug, 24 debug patches and 18 boots to change a bogus round_up() into round_down(), then let the model write the commit message. He has also said duplicate AI vulnerability reports made the private security list almost entirely unmanageable. The same person is willing to use the tools, willing to joke about them, and still unwilling to pretend rc2 has one cause.

An Extra Week If the Fixes Do Not Slow

Mainline on kernel.org is 7.3-rc2, dated September 6. The current stable kernel is 7.2.4, dated September 7. 7.1.13 went end-of-life on September 2. Testers and distribution maintainers are being asked to run the new candidate against drivers and tooling.

THE 7.3 CLOCK

1. August 30, 2026: Torvalds tags 7.3-rc1 and closes the merge window on a tree of 40.98 million lines.
2. September 1, 2026: The forgotten EDAC pull is merged after the window.
3. September 2, 2026: Kroah-Hartman posts the USB todo counts and calls the -rc cycle rough.
4. September 6, 2026: 7.3-rc2 ships as a full fat candidate with no single cause named.
5. October 18, 2026: Planned stable 7.3 date on a seven-candidate cadence.
6. October 25, 2026: The extra Sunday if an eighth candidate is required.

No systemic architectural break turned up in rc2 despite the volume. The slip date is still just a slip date. It becomes real only if this pace of incoming fixes does not ease in the weeks after the week that was supposed to be quiet.

The tarball is on kernel.org now. The USB mailbox and the net-next cleanup share will decide whether October 18 holds, not the wink that made the week easy to headline.