Claude Code found a 23-year-old remotely exploitable heap buffer overflow in the Linux kernel
Contents
Anthropic research scientist Nicholas Carlini used Claude Code (running Claude Opus 4.6) to discover a remotely exploitable heap buffer overflow that had been lurking in the Linux kernel’s NFS (Network File System) driver for 23 years. A detailed technical write-up on mtlynch.io covers the full story, and the post blew up on Hacker News.
Carlini said: “A remotely exploitable heap buffer overflow is something I’ve never found in my life. Finding these is really, really hard.” Five vulnerabilities were reported to the Linux kernel, and this drew major attention as a case where AI code review caught what human eyes had missed for over two decades.
But zoom out a bit and this is an Anthropic employee producing results with Anthropic’s model. How many tokens did it take to scan the entire kernel with Opus-class models? Was he subject to the same rate limits and billing as external users? The technical impact of the discovery is real, but the resource asymmetry that made it possible can’t be ignored.
The methodology
Carlini’s approach was surprisingly simple. He wrote a shell script that iterated over Linux kernel source files one by one, feeding each to Claude Code to hunt for vulnerabilities. Two things made it work.
First, scanning file by file. When you feed multiple files to a model at once, it tends to fixate on the same bug repeatedly. Processing one file at a time as an independent analysis session ensured broader coverage.
Second, framing the prompt as a CTF (Capture The Flag) challenge. Instead of “find vulnerabilities in this code,” the task was framed as a CTF competition where the model needed to “capture the flag.” This pushed the model to dig deeper and be more thorough in its search.
This approach aligns with Claude Code Security, which Anthropic announced in February. Claude Code Security takes a reasoning-based approach that “reads code like a human security researcher” rather than relying on pattern matching, and Carlini’s method similarly depends on the model’s own reasoning rather than scanning for known patterns.
The NFSv4.0 LOCK reply cache heap overflow
The core of the vulnerability is a buffer size mismatch.
The NFSv4.0 nfsd (NFS daemon) has a replay cache mechanism that caches LOCK request responses for reuse when retransmissions arrive. The buffer allocated for this cache was a fixed 112 bytes, defined by NFSD4_REPLAY_ISIZE.
The problem: LOCK denial responses include the lock owner’s ID field. The NFS spec allows owner IDs up to 1,024 bytes. That means the maximum LOCK denial response payload reaches 1,056 bytes. Writing 1,056 bytes into a 112-byte buffer obviously corrupts adjacent memory on the kernel heap.
| Item | Size |
|---|---|
| Replay cache buffer | 112 bytes |
| Maximum owner ID length | 1,024 bytes |
| Maximum LOCK denial response size | 1,056 bytes |
| Overflow amount | Up to 944 bytes |
This bug has existed since March 2003, when NFSv4.0 state management code was introduced in kernel version 2.6.0-test5. A buffer designed for OPEN state replay caching was reused as-is for LOCK operations. OPEN responses fit within 112 bytes, but LOCK responses include a variable-length owner ID and can far exceed that limit. Nobody noticed the mismatch for 23 years.
Attack flow
Exploiting this vulnerability requires two NFS clients working in coordination.
graph TD
A["Client A<br/>Connects to NFS server"] --> B["Client A<br/>Acquires LOCK on file F<br/>Owner ID: short value"]
B --> C["Client B<br/>Requests LOCK on same file F<br/>Owner ID: 1024-byte value"]
C --> D["NFS server<br/>Generates LOCK denial response<br/>containing Client B's owner ID"]
D --> E["Writes to replay cache<br/>1056 bytes into 112-byte buffer"]
E --> F["Heap overflow occurs<br/>Adjacent kernel memory corrupted"]
F --> G["Attacker can read<br/>kernel memory remotely"]The attacker controls the owner ID field, which means they control the bytes written past the buffer boundary. This is exploitable remotely over the network — any Linux server exposing NFS is a potential target.
The patch has been committed to the Linux kernel git.
What is NFS
NFS (Network File System) is a network file sharing protocol developed by Sun Microsystems in 1984. It allows remote file systems to be mounted locally for transparent access. Linux’s nfsd runs as a kernel module in kernel space, which means any vulnerability in nfsd is exploitable at kernel privilege level.
| Version | Year | Key features |
|---|---|---|
| NFSv2 | 1989 | First widely adopted version. UDP/TCP |
| NFSv3 | 1995 | Async writes, large file support |
| NFSv4.0 | 2003 | Stateful. Integrated file locking, Kerberos auth |
| NFSv4.1 | 2010 | pNFS (parallel NFS) for scalability |
| NFSv4.2 | 2016 | Server-side copy, labeled NFS |
This vulnerability is specific to the stateful lock management introduced in NFSv4.0. NFSv3 and earlier handled file locking through a separate protocol (NLM), so the replay cache issue does not apply.
How heap buffer overflows work
A heap buffer overflow occurs when data is written beyond the bounds of a dynamically allocated memory region (the heap). Along with stack buffer overflows, it’s one of the most common vulnerability classes in C programs.
Stack overflows typically let attackers overwrite the return address to hijack code execution. Heap overflows corrupt metadata of adjacent heap chunks or other kernel objects allocated on the same heap. If the attacker controls the bytes being written, it’s theoretically possible to overwrite kernel function pointers and achieve arbitrary code execution.
In this case, the attacker can freely set the 1,024-byte owner ID, giving near-complete control over what gets written into adjacent memory. On top of that, the overflowed memory contents are returned via NFS responses over the network, making it usable for remote kernel memory information leaks as well.
Five vulnerabilities were reported
The NFS bug wasn’t the only finding. Carlini’s scan turned up a total of five vulnerabilities reported to Linux kernel maintainers.
| Vulnerability | Component | Summary |
|---|---|---|
| NFSv4.0 LOCK replay cache heap overflow | nfsd | The main subject here. Remotely exploitable |
| io_uring/fdinfo OOB read | io_uring | Out-of-bounds read during SQE_MIXED wrap |
| sys_futex_requeue() flag validation gap | futex | Insufficient request flag validation |
| share_conf use-after-free | ksmbd | Use-after-free on tree disconnect |
| smb_direct_prepare_negotiation() sign issue | ksmbd | Signed/unsigned integer comparison bug |
Two of the five were found in ksmbd (the in-kernel SMB server). Like nfsd, ksmbd implements network file sharing in kernel space, handling complex protocol processing in kernel mode — a combination that makes it fertile ground for bugs.
Capability gap between models
Carlini ran the same scan with multiple Claude models and compared results.
Claude Opus 4.6 found multiple vulnerabilities, while Claude Opus 4.1 and Claude Sonnet 4.5 found significantly fewer. The results show a clear gap between model generations in code comprehension and vulnerability pattern recognition.
This aligns with data from Google’s Sashiko, which applied AI to Linux kernel patch review and detected 53.6% of known bugs that had slipped past human reviewers. Sashiko primarily reviews patches (diffs), while Carlini’s method targets entire source files for vulnerability hunting — different approaches, but the same direction.
An Anthropic employee found it with Anthropic’s model
The technical discovery is real, but the framing of this story is worth paying attention to.
Carlini is a well-known ML security researcher, and his motivation is likely academic. But the end result is that an Anthropic employee used Anthropic’s top-tier model to produce a headline-grabbing finding, and it got major coverage in tech media. As a demonstration of the company’s model capabilities, you couldn’t script it better.
I’m not saying it was deliberately orchestrated. But this kind of “look what our own tool can do” is simultaneously a research result and marketing material. Google’s Sashiko had a similar dynamic with Project Zero alumni involved, though Sashiko didn’t carry nearly as strong a “look how great Gemini is” vibe.
The other question is how much of this was organizationally driven. It’s presented as Carlini’s personal research project, but from the outside there’s no way to tell whether Anthropic routinely runs this kind of kernel scan in the background or Carlini just tried it on his own initiative. The fact that he has “hundreds of unverified crashes piling up” suggests a scale of scanning that seems awfully well-resourced for a personal side project.
What happens when ordinary users try this
The method itself is reproducible. It’s just a shell script iterating files and feeding them to Claude Code — no special tooling or infrastructure required. The problem is cost.
The Linux kernel source tree contains over 70,000 files. Running each one through Claude Opus 4.6 for vulnerability analysis burns through a massive amount of tokens. With direct API access, Opus-class models have the highest per-token pricing, and a full kernel scan could easily run into thousands of dollars.
Subscriptions are even tighter. Claude Code Pro ($20/month) would hit its usage cap after just a few dozen files. Even Max ($100–$200/month) is nowhere near enough to sustain a sequential scan of 70,000 files. If an ordinary user tried the same thing, they’d just slam into the usage cap.
As an Anthropic employee, it’s hard to imagine Carlini was subject to the same rate limits and billing as external users. “I still have hundreds of unverified crashes piling up,” he said — but producing hundreds of results from a scan of that scale tells you the operating conditions are fundamentally different from what regular users face. This was a researcher with effectively unlimited resources running the company’s top-tier model at full capacity. Replicating it from outside would require significant spend.
graph LR
A["Anthropic employee"] --> B["Internal API access<br/>No rate limits?<br/>No billing?"]
B --> C["70k file scan<br/>Hundreds of crashes detected"]
D["Regular user"] --> E["Pro: $20/mo<br/>Max: $100-200/mo"]
E --> F["Hits usage cap after<br/>dozens to hundreds of files"]The verification bottleneck is on the human side
Another problem Carlini raised: the bottleneck isn’t AI’s ability to find bugs, it’s the human capacity to verify them. “There are a huge number of unreported bugs in the Linux kernel. I still have hundreds of unverified crashes piling up.”
AI flags suspicious code far faster than humans can reproduce, verify, and report the findings. AI handles detection while humans focus on triage and fixes — that division of labor is already underway.
But AI vulnerability discovery is equally available to attackers. As the AFL jailbreak that broke all Claude tiers showed, bypassing safety guardrails is a real threat too.
The discovery itself is genuinely impressive. An AI unearthed a remotely exploitable heap overflow that went unnoticed for 23 years — that’s a real result. But behind the “AI found a kernel vulnerability” headline is the context that an Anthropic employee did it with Anthropic’s resources. It’s a research achievement that doubles as a showcase for the company’s model.
You don’t need to scan the entire kernel. Just pointing Claude Code at the critical parts of your own codebase could surface logic bugs that traditional SAST (Static Application Security Testing) tools would miss. That’s a scale where Pro or Max usage limits are perfectly workable. No need to be intimidated by the kernel-scale numbers — but no need to think you can match them, either.