Linus Torvalds has spent most of 2026 writing some version of the same sentence in his weekly kernel updates: a lot of this was driven by AI. With Linux 7.4-rc2, which he pushed out on Sunday evening, November 8, he said he’s going to stop repeating it, because at this point “we can just take it for granted.” But tucked into that same announcement was the first genuinely hopeful note I’ve seen about the AI bug wave all year, and less than two days later came a reminder of what that wave is costing the humans who have to review it.
Both halves of that story matter, so let’s walk through them.
First, the context. Linux 7.4 already made history a week ago when its merge window closed as the biggest ever. Phoronix counted 19,671 commits between the 7.3 release and 7.4-rc1, up from 16,267 in the 7.3 cycle and roughly 14,000 the two cycles before that. Torvalds pinned much of that on AI-assisted bug hunting, plus some developers rushing work in because 7.4 is widely expected to become the next long-term support kernel. In his rc1 announcement he said he was “*much* happier with the flood of AI triggered work going into the merge window than it showing up mainly as extra fixes during the -rc period,” and called that “a much healthier model.” Then he added the important caveat: “we’ll see how the -rc’s look.”
What rc2 actually says
Now we have our first real look. On paper rc2 is also huge, which Torvalds owned right away: “a big -rc2 to go with the largest ever -rc1.” But he argues the size is mostly cosmetic. A pile of scripted Coccinelle cleanups that arrived during the merge window got parked until rc2 because, in his words, he didn’t want to deal with them while traveling and “had a hard time finding the motivation to deal with them afterwards too.” Those are mostly one- and two-line changes scattered across thousands of files, so they bloat the diffstat without changing much.
Strip that noise out and the release looks fairly normal. Torvalds breaks it into rough thirds: drivers (mostly GPU, networking and sound), networking and BPF, and “the rest,” which is largely filesystems, memory management and architecture code. Phoronix’s rc2 rundown also flags a FAT32 performance improvement aimed at synchronous mounts and a fix for faulty BHI mitigation selection on some kernel configurations, which is the kind of everyday stabilization work an rc is supposed to carry.
The line everyone is quoting, though, is about BPF, the subsystem that lets sandboxed programs run inside the kernel and powers a huge amount of modern networking, tracing and security tooling. “This time around Alexei claims that on the bpf side at least the fixes are now coming in faster than the new reports, and that sounds lovely if true,” Torvalds wrote, referring to BPF lead Alexei Starovoitov. Starovoitov backed that up with volume: rc2 tallies credit him with around 40 BPF patches this week, many of them hardening the verifier and arena code.
Torvalds was careful not to oversell it. “I think most other areas haven’t reached that point yet, but it’s at least a sign that we _may_ be starting to see the tide starting to turn,” he wrote. “Don’t hold your breath, but maybe cross your fingers we’ll be getting there in the not entirely distant future.”
That restraint is worth taking seriously. One subsystem reaching a point where fixes outpace reports is a meaningful milestone, especially for something as security-sensitive as BPF. It is not proof the whole kernel is past the hump, and it’s one maintainer’s read of one week.
Memory management shows how big the backlog still is
If you want to see what “most other areas” looks like, check out the core memory management pull request that landed for rc2. David Hildenbrand of Arm, who helps run the newly formed Core MM tree, sent Torvalds a large batch of fixes on November 5 that weren’t ready in time for rc1. He described all of them as stable-worthy and said “the majority fixes nasty long-standing bugs instead of being purely hotfixes.”
The list is not light reading. It covers transparent huge pages, get-user-pages, KSM, userfaultfd, shmem and memfd, hugetlb and memory reclaim, with fixes for information leaks, out-of-bounds writes, data loss, use-after-free bugs, deadlocks and unkillable loops. And on where the reports came from, Hildenbrand was direct: “Most issues were reported by Anthropic. Others were found while reworking proposed fixes, and of course some of the fixes were just reported and fixed on the mailing list.” He also warned that more fixes of this kind are still in the pipeline.
That ties back to the bigger picture. As The Register notes, the volume of discovered flaws across the industry jumped after Anthropic launched its Mythos bug-finding model in April. For the kernel, that means old, subtle bugs in some of its most complicated code are finally getting found and fixed. That is genuinely good news for anyone running Linux, which is basically everyone. It also means someone has to read, verify and land every one of those patches.
Which brings us to the less cheerful part of the week. On Tuesday, November 10, longtime memory management developer Lorenzo Stoakes of Arm, who has been contributing to the kernel since 2014 and wrote the book The Linux Memory Manager, posted patches removing himself as a reviewer for the MM, core, misc and Rust areas. He’ll stay on as maintainer for the parts he directly oversees. His reasoning was plain: “Given the current throughput in the kernel resulting from AI-generated series, I unfortunately lack the bandwidth to generally be able to offer review except in those areas I maintain.” He closed by saying he wants “to make my inbox a little more manageable.”
That’s not a dramatic exit, and it shouldn’t be spun as one. But it’s an honest data point. AI tools can find bugs and draft patches at a pace no team of humans can match, and the kernel’s whole quality model depends on experienced people reviewing changes before they land. Torvalds himself noted in his rc1 mail that AI-suggested patches “often get rewritten.” When the people doing that rewriting start trimming their review load, that’s the bottleneck showing.
Cody’s take
I’m genuinely encouraged by rc2, but in a measured way. The good news is real: one of the kernel’s most security-critical subsystems might finally be outrunning its bug reports, and long-hidden memory management bugs are getting fixed instead of sitting there waiting to be exploited. If AI-assisted bug hunting ends up making the next LTS kernel one of the most thoroughly scrubbed releases in years, that’s a win for servers, Steam Decks, Android phones and everything in between.
The catch is that “fixes are outpacing reports” in BPF this week doesn’t mean the humans are keeping up everywhere, and Stoakes stepping back from review is the clearest sign yet that the burden is landing on a relatively small group of experienced maintainers. Tooling that finds bugs needs to be matched by tooling and funding that helps review them, or the kernel trades one problem for another.
For regular users, the practical advice hasn’t changed. 7.4-rc2 is a test build for developers and enthusiasts, so stick with your distro’s stable kernel. If the usual schedule holds, the final 7.4 release should land around the end of December, likely December 20 or 27 depending on whether Torvalds needs seven or eight release candidates, and its LTS status still has to be confirmed. The next few rc announcements will tell us whether rc2’s hopeful note was a turning point or just a good week. I’ll be watching.
Author
.jpg){kind=link}
