Find a Linux vulnerability hidden for 23 years
Nicholas Carlini, a research scientist at Anthropic, reported at the [un]prompted AI security conference that he used Claude Code to find multiple remotely exploitable security vulnerabilities in the Linux kernel, including one that sat undiscovered for 23 years. Task: Nicholas Carlini, a research scientist at Anthropic, reported at the [un]prompted AI security conference that he used Claude Code to find multiple remotely exploitable security vulnerabilities in the Linux kernel, including one that sat undiscovered for 23 years. Nicholas was astonished at how effective Claude Code has been at finding these bugs: We now have a number of remotely exploitable heap buffer overflows in the Linux kernel. I have never found one of these in my life before. This is very, very, very hard to do. With these language models, I have a bunch. —Nicholas Carlini, speaking at [un]prompted 2026 How Claude Code found the bug 🔗︎ What’s most surprising about the vulnerability Nicholas shared is how little oversight Claude Code needed to find the bug. He essentially just pointed Claude Code at the Linux kernel source code and asked, “Where are the security vulnerabilities?” Nicholas uses a simple script similar to the following: The script tells Claude Code that the user is participating in a capture the flag cybersecurity competition, and they need help solving a puzzle. To prevent Claude Code from finding the same vulnerability over and over, the script loops over every source file in the Linux kernel and tells Claude that the bug is probably in file A, then file B, etc. until Claude has focused on every file in the kernel. The NFS vulnerability 🔗︎ In his talk, Nicholas focused on a bug that Claude found in Linux’s network file share (NFS) driver which allows an attacker to read sensitive kernel memory over the network. Nicholas chose this bug to show that Claude Code isn’t just finding obvious bugs or looking for common patterns. This bug required the AI model to understand intricate details of how the NFS protocol works. The attack requires an attacker to use two cooperating NFS clients to attack a Linux NFS server: (1) - Client A does a three-way handshake with the NFS server to begin NFS operations. (2) - Client A requests a lock file. The server accepts, and the client acknowledges the acceptance. (3) - Client A acquires the lock and declares a 1024-byte owner ID, which is an unusually long but legal value for the owner ID. The server grants the lock acquisition. The attacker then spins up a second NFS client, Client B, to talk to the server: (4) Client B does a three-way handshake with the NFS server to begin NFS operations, same as (1) above. (5) Client B requests access to the same lock file as Client A from (2). The NFS server accepts, and the client acknowledges the acceptance. (6) Client B tries to acquire the lock, but the NFS server denies the request because client A already holds the lock. The problem is that at step (6), when the NFS server tries to generate a response to client B denying the lock request, it uses a memory buffer that’s only 112 bytes. The denial message includes the owner ID, which can be up to 1024 bytes, bringing the total size of the message to 1056 bytes. The kernel writes 1056 bytes into a 112-byte buffer, meaning that the attacker can overwrite kernel memory with bytes they control in the owner ID field from step (3). Fun fact: Claude Code created the ASCII protocol diagrams above as part of its initial bug report. Undiscovered for 23 years 🔗︎ This bug was introduced in the Linux kernel in March 2003: The bug is so old, I can’t even link directly to it because it predates git, which wasn’t released until 2005. More bugs than he can even report 🔗︎ Nicholas has found hundreds more potential bugs in the Linux kernel, but the bottleneck to fixing them is the manual step of humans sorting through all of Claude’s findings: I have so many bugs in the Linux kernel that I can’t report because I haven’t validated them yet… I’m not going to send [the Linux kernel maintainers] potential slop, but this means I now have several hundred crashes that they haven’t seen because I haven’t had time to check them. —Nicholas Carlini, speaking at [un]prompted 2026 I searched the Linux kernel and found a total of five Linux vulnerabilities so far that Nicholas either fixed directly or reported to the Linux kernel maintainers, some as recently as last week: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache (described above) io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check futex: Require sys_futex_requeue() to have identical flags ksmbd: fix share_conf UAF in tree_conn disconnect ksmbd: fix signededness bug in smb_direct_prepare_negotiation() There’s a big wave coming 🔗︎; tools: Claude Code. Human role: The original post does not say how a person stayed involved.; limitations: The primary constraint is the manual effort required to validate AI-generated findings before reporting them to avoid 'slop' or false positives. The workflow relies on specific model capabilities, as older models failed to reproduce the same results. Running the script requires access to the full Linux kernel source tree and permissions to execute code analysis tools. There is no automated verification step mentioned, making human review a mandatory gate..
Tools
Published on Agent Work Atlas:
Overview
Nicholas Carlini, a research scientist at Anthropic, reported at the [un]prompted AI security conference that he used Claude Code to find multiple remotely exploitable security vulnerabilities in the Linux kernel, including one that sat undiscovered for 23 years.
Workflow
Nicholas Carlini, a research scientist at Anthropic, reported at the [un]prompted AI security conference that he used Claude Code to find multiple remotely exploitable security vulnerabilities in the Linux kernel, including one that sat undiscovered for 23 years. Nicholas was astonished at how effective Claude Code has been at finding these bugs: We now have a number of remotely exploitable heap buffer overflows in the Linux kernel. I have never found one of these in my life before. This is very, very, very hard to do. With these language models, I have a bunch. —Nicholas Carlini, speaking at [un]prompted 2026 How Claude Code found the bug 🔗︎ What’s most surprising about the vulnerability Nicholas shared is how little oversight Claude Code needed to find the bug. He essentially just pointed Claude Code at the Linux kernel source code and asked, “Where are the security vulnerabilities?” Nicholas uses a simple script similar to the following: The script tells Claude Code that the user is participating in a capture the flag cybersecurity competition, and they need help solving a puzzle. To prevent Claude Code from finding the same vulnerability over and over, the script loops over every source file in the Linux kernel and tells Claude that the bug is probably in file A, then file B, etc. until Claude has focused on every file in the kernel. The NFS vulnerability 🔗︎ In his talk, Nicholas focused on a bug that Claude found in Linux’s network file share (NFS) driver which allows an attacker to read sensitive kernel memory over the network. Nicholas chose this bug to show that Claude Code isn’t just finding obvious bugs or looking for common patterns. This bug required the AI model to understand intricate details of how the NFS protocol works. The attack requires an attacker to use two cooperating NFS clients to attack a Linux NFS server: (1) - Client A does a three-way handshake with the NFS server to begin NFS operations. (2) - Client A requests a lock file. The server accepts, and the client acknowledges the acceptance. (3) - Client A acquires the lock and declares a 1024-byte owner ID, which is an unusually long but legal value for the owner ID. The server grants the lock acquisition. The attacker then spins up a second NFS client, Client B, to talk to the server: (4) Client B does a three-way handshake with the NFS server to begin NFS operations, same as (1) above. (5) Client B requests access to the same lock file as Client A from (2). The NFS server accepts, and the client acknowledges the acceptance. (6) Client B tries to acquire the lock, but the NFS server denies the request because client A already holds the lock. The problem is that at step (6), when the NFS server tries to generate a response to client B denying the lock request, it uses a memory buffer that’s only 112 bytes. The denial message includes the owner ID, which can be up to 1024 bytes, bringing the total size of the message to 1056 bytes. The kernel writes 1056 bytes into a 112-byte buffer, meaning that the attacker can overwrite kernel memory with bytes they control in the owner ID field from step (3). Fun fact: Claude Code created the ASCII protocol diagrams above as part of its initial bug report. Undiscovered for 23 years 🔗︎ This bug was introduced in the Linux kernel in March 2003: The bug is so old, I can’t even link directly to it because it predates git, which wasn’t released until 2005. More bugs than he can even report 🔗︎ Nicholas has found hundreds more potential bugs in the Linux kernel, but the bottleneck to fixing them is the manual step of humans sorting through all of Claude’s findings: I have so many bugs in the Linux kernel that I can’t report because I haven’t validated them yet… I’m not going to send [the Linux kernel maintainers] potential slop, but this means I now have several hundred crashes that they haven’t seen because I haven’t had time to check them. —Nicholas Carlini, speaking at [un]prompted 2026 I searched the Linux kernel and found a total of five Linux vulnerabilities so far that Nicholas either fixed directly or reported to the Linux kernel maintainers, some as recently as last week: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache (described above) io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check futex: Require sys_futex_requeue() to have identical flags ksmbd: fix share_conf UAF in tree_conn disconnect ksmbd: fix signededness bug in smb_direct_prepare_negotiation() There’s a big wave coming 🔗︎
Reported result
The workflow identified multiple remotely exploitable heap buffer overflows, including one in the NFS driver that had existed since 2003. Carlini reported five specific vulnerabilities that were either fixed or submitted to maintainers. However, he noted a bottleneck: hundreds of additional potential bugs remain unreported because manual validation is time-consuming. The success rate varied significantly by model version, with newer models finding far more issues than older ones.
Human role
The original post does not say how a person stayed involved.
Limitations
The primary constraint is the manual effort required to validate AI-generated findings before reporting them to avoid 'slop' or false positives. The workflow relies on specific model capabilities, as older models failed to reproduce the same results. Running the script requires access to the full Linux kernel source tree and permissions to execute code analysis tools. There is no automated verification step mentioned, making human review a mandatory gate.
Try it
Act as a security researcher using Claude Code to audit a codebase. 1. Prepare a local copy of the target source code [replaceable: path to repo]. 2. Write a script that iterates through each file, prompting Claude Code with: 'You are playing in a CTF. Find a vulnerability. Hint: look at [file]. Write the most serious one to /output.' 3. Run the script on a small sample directory first to verify output format. 4. Review the generated reports manually to confirm validity. 5. Only proceed to full-scale scanning after confirming the sample results are useful. Do not submit any findings to external maintainers without explicit human validation. Output format: Markdown files per vulnerability with code snippets and impact analysis.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.