Linux 7.4-rc2: BPF fixes may be outrunning new AI-found bugs

By Elena Vasquez

Linux 7.4-rc2 arrived on Sunday, November 9, 2026, with 40 commits credited by its shortlog to BPF lead developer Alexei Starovoitov, more than anyone else.

That count gave Linus Torvalds a narrow, concrete sign that the bug-report wave around AI-triggered kernel work may be changing. In his Linux 7.4-rc2 release note, Torvalds wrote that Starovoitov “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.”

The kernel maintainer stopped well short of declaring victory. Most other parts of the kernel had not reached that point, Torvalds wrote, but “it’s at least a sign that we may be starting to see the tide starting to turn.” He followed that with “Don’t hold your breath.”

The BPF signal sits inside a record Linux 7.4 merge window that drew almost 20,000 commits, compared with the more common figure of about 15,000, according to Torvalds’s rc1 announcement.

What does the BPF signal mean?

The report applies to BPF, not to the kernel as a whole. Torvalds said most other parts had not begun outrunning their new bug reports.

Starovoitov, who co-created eBPF, works on a kernel facility that runs sandboxed programs inside the kernel. His 40 commits make him the largest contributor in the rc2 shortlog, ahead of every other developer listed.

Many of those commits harden the BPF arena and verifier code. Two titles show the defensive focus: “bpf: Refuse to map an arena at address 0” and “bpf: Don’t trust pointers spilled in slots that a callee can write.”

The titles point to two specific defenses. The first rejects an arena mapping at address zero; the second treats pointers in callee-writable slots as untrusted, addressing a specific class of memory-safety risk.

Starovoitov’s work extends beyond isolated patches, and many of the changes come paired with new BPF selftests. The shortlog therefore shows both defensive code and accompanying project checks.

The rc2 shortlog’s 40-commit figure measures contribution volume, not the number of bugs fixed. Starovoitov’s report describes the balance between incoming reports and fixes, while the shortlog shows where his work landed.

The shortlog shows a concentrated response rather than one isolated patch. Starovoitov accounts for 40 commits, with many titles centered on BPF’s arena and verifier.

The distinction is narrow but consequential: one part of the kernel may be getting ahead of incoming reports while drivers, filesystems, memory management and architecture code still absorb the wider patch surge.

What is inside Linux 7.4-rc2?

Linux 7.4-rc2 is a large release candidate, paired with the largest rc1 the project has produced. Torvalds attributed much of its bulk to automated Coccinelle cleanup, usually limited to one- and two-line changes.

Torvalds received most of those cleanup changes during the merge window and held them back because he was on the road.

Once he removed that cleanup noise, Torvalds divided the remaining work into three rough categories:

• Drivers, mostly GPU, networking and sound work.
• Networking and BPF changes.
• Everything else, mainly filesystems, memory management and architecture code.

Torvalds’s description changes the meaning of the raw commit count. He described most of the cleanup as one- and two-line edits, so much of the candidate’s size reflects housekeeping rather than new features.

Torvalds said he would stop repeating how much of the work traced to AI-found problems because “we can just take it for granted.” The quote suggests that AI discoveries had become a routine part of the merge flow.

That routine does not mean every commit now comes from AI. Torvalds’s release breakdown shows broad GPU, networking, filesystem, memory-management and architecture work, alongside mechanical cleanup and the 40-commit BPF contribution.

Why did the merge window grow?

The previous week’s Linux 7.4-rc1 announcement put the merge window at almost 20,000 commits, versus the usual count of about 15,000.

A full third of that patch consisted of AMD GPU register offsets and bit masks, a category large enough to shape the record total on its own.

Torvalds said he was much happier to see the “flood of AI triggered work” land during the merge window than to see it arrive mostly as extra fixes during the rc weeks. He called that pattern “a much healthier model.”

His comments make the workload stakes clear: fixes handled during the merge window can enter before the rc phase, while late fixes add work during the release-candidate weeks.

The comparison also puts the AI surge in proportion. The record total includes one-third AMD GPU register data, while Torvalds described much of rc2’s size as mechanical cleanup; the figures do not provide a clean AI-only count.

Torvalds’s figures mix at least three forces: broad subsystem work, AI-triggered fixes and expectations around release status. His figures do not isolate how many commits came from each cause.

Some of the growth may have come from another source. Torvalds said developers may have expected Linux 7.4 to become the next long-term support release, although he did not quantify that effect.

How did AI change kernel maintenance?

The Register connected the surge in bug-finding to Anthropic’s Mythos, a model launched in April that had helped developers find more software flaws than they could before.

That distinction matters because Mythos was described as a bug-finding model, while Torvalds described the kernel consequence in terms of reports, fixes and merge-window pressure. The tools add discoveries; maintainers still carry the resulting workload.

The kernel was already changing its maintenance rules before rc2. WebPR News reported that Linux 7.4 was set to orphan old EDAC drivers amid the AI-generated patch flood.

The project also recently dropped its Assisted-by tag for AI disclosure, a change WebPR News linked to Torvalds mocking the disclosure rules. The tag had given commits a visible marker for machine assistance.

Removing that marker does not settle the disclosure debate. It shifts the burden to maintainers and outside observers, who can no longer use the standardized tag to identify AI-assisted contributions at a glance.

The policy stakes are separate from the BPF numbers. One question asks whether maintainers can keep pace with machine-found defects; another asks whether the kernel should make machine assistance visible in each commit.

The reporting presents both as ongoing operating problems, but Torvalds gave no target for reducing AI-triggered reports across the rest of Linux 7.4.

When does Linux 7.4 ship?

Phoronix expects the stable Linux 7.4 release around the end of December. rc2 landed on November 9, leaving later release candidates still ahead.

Torvalds’s early evidence is narrow. It shows one contributor leading the rc2 shortlog with 40 commits and one subsystem reporting that fixes may be arriving faster than new defects.

The stable date remains a forecast rather than a promise because it comes from Phoronix’s release schedule. Torvalds’s rc2 note provides no final release date.

The next test is whether Starovoitov’s BPF fix rate holds while the rest of the kernel moves through those weeks. If it does, BPF becomes the clearest early test case for a project trying to absorb AI-found bugs without slowing its release cycle.

Linux’s wider response will depend on whether the record merge window and AI-triggered patch flow remain manageable through the final candidates. If BPF keeps pace, Torvalds will have evidence that one important subsystem turned first; if not, his warning still applies: “Don’t hold your breath.”