Linux 7.3-rc4 blocks dangerous Granite Rapids microcode and cleans up LLM-caught bugs

September 20, 2026. Linus Torvalds releases Linux 7.3-rc4. August 30, 2026. The 7.3 cycle opened with its first candidate. October 18, 2026. The stable release is expected if no rc8 is needed. Why it matters: this candidate is “bigger than usual” for this stage of the cycle, and it fixes both a hardware risk on Intel Granite Rapids servers and a wave of error-path bugs caught by LLMs.

An unusually large rc4

In his announcement mail, Torvalds notes the candidate’s size remains “noticeably larger than normal” for an rc4. The code breakdown is itself unusual: normally dominated by drivers, this week’s changes split into three near-equal thirds — one-third drivers, one-third filesystems and networking, one-third misc (architecture fixes, core kernel, developer tools).

The single largest patch of the week fixes nothing: it deletes a leftover file. During the merge window, lib/alloc_tag.c was moved into the mm/ directory, but the original copy accidentally remained until its removal in this rc4. A minor detail that captures the candidate’s nature: deep cleanup.

This three-way split signals a consolidation cycle rather than a feature cycle. When filesystems and networking weigh as much as drivers, maintainers are paying down accumulated stability debt — the rarely exercised code paths that neither tests nor users cover. For a kernel destined to carry file servers and network gateways in production, that is exactly the kind of invisible work that prevents incidents. The Granite Rapids erratum is the same pattern at the hardware boundary: the kernel now refuses a microcode revision that is safe only in sequence, protecting servers from a machine-check exception that would otherwise look like a random crash and get blamed on the hardware vendor.

Granite Rapids: the dangerous microcode blocked

The most decisive fix concerns Intel Granite Rapids (Xeon 6). The kernel now explicitly rejects problematic microcode updates on these servers. Revision 0x1000405 carries internal changes required by later revisions, but can trigger a machine check exception if loaded on a system not already updated to 0x1000405.

Intel’s specification update lists the erratum as GNR98, attributed to the inter-microcode communication interface. A second erratum, GNR101, stems from an incorrect minimum runtime microcode revision in version 0x1000423. The kernel therefore blocks loading 0x1000405 or later — in both early and late loading — until the system is already current. The fix is marked for backporting to existing stable branches.

The x86 batch also addresses two more user-facing cases. Intel FRED on Panther Lake was causing some games to crash or freeze under Wine and Steam Play: the fix is merged. And kernels built with -march=native on upcoming APX platforms could use the extended EGPR registers (R16–R31) before the kernel was ready — the code now explicitly blocks that use until APX support lands in-kernel.

Filesystems in the front line

Filesystems absorb an unusual share of the 7.3 cycle’s attention. NTFS gains dynamic MFT tail reservations and repacked $MFT record lists, with new locks protecting runlist updates from races.

SMB and CIFS receive several stability fixes: correct enforcement of SMB2 session expiration rules, lease-break acknowledgements sent through the right session for multi-user mounts, and fixes for memory leaks and use-after-free bugs on interface teardowns. Btrfs restores stable filesystem IDs: f_fsid is now derived from dev_t only when an active temp_fsid exists.

The rest of the kernel follows. SELinux preserves user SIDs across nested backing files and rechecks intermediate files during memory-protection changes. xfrm serializes state garbage collection. Bluetooth validates service data lengths before reading UUIDs from packet headers. ARM64 hibernation now clones only the linear map that actually exists at runtime.

LLMs enter the fix cycle

The freshest angle of this rc4 is editorial. Torvalds flags a surge of small error-path cleanups across many drivers, and notes that large language models appear “particularly effective” at catching these obscure error-handling flaws.

Most desktop users will never hit these rare failure paths. But under a sudden hardware glitch or an allocation failure, these fixes prevent hard crashes and keep the system running. It is the first time LLM-assisted bug hunting reads this clearly in a kernel release mail — a signal worth watching for maintainers and for teams instrumenting their own code.

The practical upshot for a tester is concrete. If you run 7.3-rc4 on Granite Rapids, the microcode block is the headline; if you play Windows titles through Wine on Panther Lake, the FRED fix is the one you will notice. Everything else in this candidate is the quiet, invisible work of a kernel maturing toward its October stable release.

What it means for distributions

The schedule gives the roadmap. rc5 is expected on September 27, rc6 on October 4, rc7 on October 11, and the stable release on October 18 — barring an rc8, which would push it to October 25. Major distributions usually start integrating a kernel a few weeks after its stable release, so the Granite Rapids fixes will land in server distributions’ security updates shortly after.

For an SRE or system administrator, the reflex is twofold. On servers, watch the distribution’s update channel: the 0x1000405 microcode block will be backported to stable branches, and that is where it matters most — on Xeon 6 hardware in production. On workstations, do nothing: the FRED and APX fixes will ride along with the stable kernels that desktop distributions ship.

The LLM signal matters beyond the kernel

The trend is worth noting for reasons that go beyond Linux. If LLMs are good enough at spotting error-handling flaws that Torvalds credits them in a release mail, then the same tooling is coming for your codebase — and much of it is already available. The kernel is a hard target: decades of review, thousands of eyes, and still the models find bugs worth merging. That is a signal for every team still treating AI-assisted code review as a gimmick rather than a first pass that catches the rare failure paths human review tends to skip.

Verdict

Linux 7.3-rc4 is a stabilization candidate that fixes concrete risks, not hypotheticals. If you are testing 7.3 on Intel Granite Rapids servers, update immediately: blocking microcode 0x1000405 prevents a possible machine check. If you game under Wine on Panther Lake, this fix resolves freezes and crashes. If you are in production, stay on a stable branch — the final release is expected on October 18, 2026, barring an rc8 that would push it to October 25. The real takeaway is elsewhere: LLMs are now a measurable correction force in the kernel cycle.

References

• Phoronix — Linux 7.3-rc4 Released: More Fixes Caught By LLMs, But Nothing Too Scary (September 20, 2026)
• Phoronix — Important x86 Fixes Merged Ahead Of Linux 7.3-rc4 (September 20, 2026)
• OSTechNix — Linux Kernel 7.3 RC4 Released: Bigger Than Usual With LLM Bug Fixes (September 21, 2026)
• Linus Torvalds — Linux 7.3-rc4 announcement mail