# Linux 7.3-rc4 arrives with LLM-caught error path fixes

URL: https://techaiwire.com/articles/linux-7-3-rc4-llm-caught-error-path-fixes/

_By Claire Whitmore - Sep 21, 2026_

**By the numbers:**

- 1/3 - of the rc4 fixes that sit in drivers
- 2 - Btrfs bugs fixed in this prepatch
- 2023 - when the silent data-loss bug was introduced

Linus Torvalds released Linux 7.3-rc4 on September 20, 2026, and singled out large language models as a useful source of one specific kind of bug report. [Phoronix](https://www.phoronix.com/news/Linux-7.3-rc4) quotes him saying that "various LLM's seem to be pretty good at catching" problems in error path cleanup code. That is a narrow claim from the kernel's most senior maintainer, and it is more interesting than a routine prepatch.

A prepatch, or release candidate, is a test build issued weekly while a kernel version stabilizes. Torvalds described this one as "large", according to [LWN](https://lwn.net/Articles/1095491/), adding that this is unsurprising at this point in the cycle.

## Why error paths are the part LLMs catch

Error path cleanup is a known weak spot in C code, and the kernel is full of it. A function acquires a lock, allocates memory, takes a reference on an object, and then hits a failure partway through. Everything acquired so far has to be released, in reverse order, before the function returns.

The successful path through such a function gets exercised constantly. The failure paths often do not run at all in normal use, so a leak or a missing unlock can sit there for years without anyone noticing.

That shape is also why a model can find these bugs. The mistake is local and visible in a single function: something was acquired and not released. A reviewer does not need to understand the whole subsystem to see it, and neither does a model. It is pattern matching against a rule the kernel applies everywhere.

This is a much more modest claim than saying models can write kernel code. Torvalds is describing a class of defect where the reasoning is shallow and the volume of code is enormous, which is the combination automated tooling has always handled well.

## What else is in rc4

Phoronix reports the fixes falling into roughly even thirds: about one third in drivers, one third across filesystems and networking, and one third in architecture and tooling code.

| Area | Examples reported |
| --- | --- |
| Architecture | x86 and x86_64 fixes |
| Filesystems | Two Btrfs bugs, plus SMB and NTFS changes |
| Drivers | New XPad game controller support |

One fix stands out. Phoronix reports a patch for a bug that silently lost user-space data, and that the defect had been present since 2023. Silent data loss is the worst category of kernel bug, because nothing fails visibly at the time and the damage is discovered later, if ever.

The Btrfs work continues a thread from earlier in this cycle, when [fixes for filesystem IDs and grub2 boot](/articles/linux-7-3-btrfs-fsid-grub2-boot-fixes/) were queued for this same prepatch. Linux 7.3 final is scheduled for October 2026.

## What this means for developers

Take the LLM claim at the size it was made. Torvalds named error path cleanup, not correctness in general. If you want to copy the result, point a model at your own failure paths. Ask it one bounded question: does every early return release what the function acquired above it? That is a different exercise from asking a model whether your code is correct, and it is the one with evidence behind it.

Compare it against what you already run. The kernel has used static analysis for this class of bug for many years through tools like Coverity and smatch. The interesting question is not whether models find error path bugs, but whether they find ones those tools miss, and at what false-positive rate. Nothing in these reports answers that, so treat it as an open question rather than a settled win.

The reporting workflow matters more than the finding. A model produces a plausible-looking patch as easily as a real one, and a maintainer cannot tell the difference without doing the review themselves. If you submit a fix you found this way, verify it yourself first and say how you found it. Keep the patch small enough that a reviewer can check it in one sitting.

For anyone tracking 7.3, this is the ordinary signal to start testing. Torvalds called this one large without calling it alarming. At that point in the cycle the shape of the release is set, and the remaining weeks are for polish. If you maintain out-of-tree modules or a distribution kernel, build against rc4 now rather than waiting for the October release. Ubuntu 26.10 is already [shipping a pre-release 7.3 kernel](/articles/ubuntu-26-10-linux-7-3-prerelease-kernel/), so some users will meet this code before it is final.

The 2023 data-loss bug is the practical reminder in this release. A defect that quietly discards user data survived three years in a kernel read by more people than almost any other codebase. That is an argument for more automated checking of the paths nobody runs, whatever tool ends up doing it.

The final Linux 7.3 was released on October 18, 2026. See [Linux 7.3 released with fchroot, failfs and faster Btrfs](/articles/linux-7-3-released-fchroot-failfs-btrfs-sched-ext/).

## Sources

- [Kernel prepatch 7.3-rc4](https://lwn.net/Articles/1095491/) - LWN.net
- [Linux 7.3-rc4 Released: More Fixes Caught By LLMs, But Nothing Too Scary](https://www.phoronix.com/news/Linux-7.3-rc4) - Phoronix