Claude Code Found a Linux Vulnerability Hidden for 23 Years
81 points by mtlynch
81 points by mtlynch
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.
I don't think this is true. This is believing that all output of the tool was necessary to reach the final state.
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).
This also could have been found by attribute testing and/or fuzzing. Neither of those tools would have understood the protocol. Therefore understanding the protocol is not necessary.
I think the main thing this shows is that a high level of required effort has been a barrier to thorough testing of some parts of the kernel and that Claude et al drastically lower the effort required.
This also could have been found by attribute testing and/or fuzzing.
Carlini says in the talk, "You would never find this by fuzzing."
I was a little surprised because I would have thought you could, but I can't think of a path where you would in practice.
You'd have to have a fuzzer that not only fuzzes request payloads but it would have to randomly generate sequences of requests across multiple clients so that you get this outcome because this can only happen with parallel clients hitting this unusual payload in the correct sequence.
That's sort of my point though. I'm not sure Carlini and I disagree. I was saying the gap between could and would is the effort required to setup the fuzzer. I agree that you would not find this with a fuzzer today. But a fuzzer could expose the missing bounds check without any understanding of the protocol and someone familiar with the NFS protocol could envision this sequence. In fact, it is nearly predicted by the original change description. They knew they needed to accommodate the LOCK message but forgot about their own caveat by the time they got around to it.
I also agree that almost no one would find this with a fuzzer today. Even someone who took the effort would likely struggle to understand the sequence. Consider for a second the difference between the title:
Claude Code Found a Linux Vulnerability Hidden for 23 Years
And an alternative title:
Claude Code Found a Linux NFS Vulnerability Hidden for 23 Years
I think this sort of highlights why Carlini was enthusiastic about the output of Claude. It explained the decades old protocol context that he likely didn't have top of mind. That is very helpful! I don't mean to downplay the usefulness of Claude as a vulnerability hunting tool. I just want us to be honest that it is the engineer who needs the understanding of the protocol (in both cases) rather than the tool.
I also think the timeline works the other way around too though. I think fuzzing tools are much more capable today than they were in 2003. Had the original developer had today's fuzzing tools and today's computers, I think they also likely could have easily exposed this bug since they would have had the focus and motivation to secure this code to the extent possible. I think that is notable because older code, which was subject to many fewer security review tooling, is likely the deepest well of these vulnerabilities rather than this being an infinite stream of vulnerabilities discovered as a function of the number of new lines of code produced.
I research fuzzing quite intently, and I generally agree that this bug still would be unlikely to be found with a currently existing fuzzer. nyx-net probably gets close, but these combinations of protocol state and program state bugs are notably hard to find by mutational search (see the syzkaller takeaway). That said, I don't think that this precludes the existence of a fuzzer that could find this; it's just that current ones couldn't.
All of this is a distraction though. Of course you will find new bugs when new tools are released; that is one of the core realizations of the fuzzing community. The takeaway here is one that the fuzzing community has been saying for years: the only reason our tools work is because of bad development practices for which relatively shallow bugs can be found via program search. The Linux kernel still being predominantly written in memory unsafe languages is insane from a security and safety perspective, and such bugs will continue to emerge regardless. It's interesting that LLMs are getting better at finding these things, but it's not the end of the world, it's just a new technique.
You can use LLM as a fuzzer. In fact thats one of the things its good at as it generates plausible code. Write a test that should not pass, and let it generate answers until the test passes, no human interaction required.
I would not use an LLM as a fuzzer; we generate inputs way, way faster than that. Using it to generate harnesses is fine. Even generating plausible seed inputs is fine. But I would never use it in the main mutational/generational loop of a fuzzer.
Given the description of the bug - where two different NFS clients need to perform a complex sequence of interactions in the right order - I can absolutely believe that fuzzing would not have found this.
Which description? The one with the diagram? If so, that's my point. That diagram is being produced by Claude. You think those are the necessary steps because it is explaining those steps to you as the one path it happened to describe. We actually have no idea if it was necessary to Claude finding the vulnerability. And regardless of whether Claude could have found it without generating and consuming those tokens, the description of the actual fix describes the same process much more simply.
This description:
- Client A does a three-way handshake with the NFS server to begin NFS operations.
- Client A requests a lock file. The server accepts, and the client acknowledges the acceptance.
- 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.
- Client B does a three-way handshake with the NFS server to begin NFS operations, same as (1) above.
- Client B requests access to the same lock file as Client A from (2). The NFS server accepts, and the client acknowledges the acceptance.
- Client B tries to acquire the lock, but the NFS server denies the request because client A already holds the lock.
I know it's tempting to discount this because "Fun fact: Claude Code created the ASCII protocol diagrams above as part of its initial bug report" but Nicholas Carlini's reputation is such that I do not think he's in the business of publishing unverified slop.
but Nicholas Carlini's reputation is such that I do not think he's in the business of publishing unverified slop.
Hyperbole much? Jesus. I actually praised the description Claude gave as helpful elsewhere in this discussion.
Carlini has a strong reputation as a security researcher. Not as an AI researcher. He has zero way of knowing whether the generation and consumption of the protocol description tokens was necessary for it to generate the description of the bug it gave him. Anthropic expends a lot of effort researching how these models work internally and they can't discern this yet either.
What happened is this: Carlini needed help understanding the protocol flow that was necessary to exploit the bug. The model gave it to him. And because it was the uniquely helpful part for him he mistakenly attributed the seeming "understanding" of those details as a necessary part of the description of the missing bounds check. He anthropomorphized it because the only terms he had for his very human problem was human actions.
Claude Code isn’t just finding obvious bugs or looking for common patterns.
There is no "looking" at all. There is token generation and consumption with reinforcement feedback as a guide. As Karpathy says, it is all hallucination.
The fact of the matter is there is insufficient evidence exported by Claude and insufficient understanding of how to explore these models exhaustively to say whether the actual description of the bug would have or could have been generated by Claude without also generating the description of the protocol.
If you read very closely, I hope you'll see that my claim is actually that AI might be more capable for finding vulnerabilities than Carlini is claiming. If "understanding" of the protocol is not necessary to find the bugs because they can be generated from the code patterns alone, then we will find many more bugs than we will if information about the user of the code is also required.
This also could have been found by attribute testing and/or fuzzing. Neither of those tools would have understood the protocol. Therefore understanding the protocol is not necessary.
I don't disagree with you that the bug could have been found different ways, but I think it's fair to say if it wasn't found for 23 years and it was found via this method that alone is impressive.
OK so a security researcher (with actual knowledge and experience) digs through 100s of bogus security bugs. Finds a couple using Claude Code, and the headline is that Cloud Code found the bugs?
That's not what he said in the talk. He said he found hundreds using claude, but he is validating them to make sure he's not drowning lkml in slop reports, so only a handful have been reported so far[1]. His main point was not that he's finding one or two, but that recent models are finding these at a rapidly accelerating pace.
Quoting his slides: LLMs can autonomously, and without fancy scaffolding, find and exploit 0days in critical software. And they are getting good scarily fast...Current LLMs are better vulnerability researchers than I am...Future LLMs will likely be better than any of us. (us, here, being the room full of vulnerability researchers he was talking to)
[1] as well as the talk https://www.youtube.com/watch?v=1sd26pWhfmg , Nicholas had a blog post at https://red.anthropic.com/2026/zero-days/ which says we've found and validated more than 500 high-severity vulnerabilities (with claude 4.6) - tho the context doesn't make it clear what projects they were in; the talk mentions targets other than the kernel
"Months ago, we were getting what we called 'AI slop,' AI-generated security reports that were obviously wrong or low quality," he said. "It was kind of funny. It didn't really worry us."
…
Things have changed, Kroah-Hartman said. "Something happened a month ago, and the world switched. Now we have real reports." It's not just Linux, he continued. "All open source projects have real reports that are made with AI, but they're good, and they're real." Security teams across major open source projects talk informally and frequently, he noted, and everyone is seeing the same shift. "All open source security teams are hitting this right now."
"AI bug reports went from junk to legit overnight, says Linux kernel czar" - https://www.theregister.com/2026/03/26/greg_kroahhartman_ai_kernel/
OK so a security researcher (with actual knowledge and experience) digs through 100s of bogus security bugs. Finds a couple using Claude Code, and the headline is that Cloud Code found the bugs?
We don't know how many were false positives. It's possible that 80% or more of what Claude Code produced were legitimate findings, but it takes time to even triage legitimate bugs as valid because the Linux kernel is complex.
What would the false positive rate have to be for you to consider Claude Code to be the primary party responsible for discovering the vulnerability?
I can understand if only 1% are legitimate and the researcher has to sift through to find them, then the researcher is doing heavy lifting. And clearly if it's 95% accurate, that's essentially Claude Code finding everything, but what's the boundary where one wouldn't consider the findings to be coming from Claude Code?
We don't know how many were false positives. It's possible that 80% or more of what Claude Code produced were legitimate findings, but it takes time to even triage legitimate bugs as valid because the Linux kernel is complex.
Speaking purely hypothetically. 90% of the issues Claude finds are real. Many are minor. Some of the proposed fixes are wrong.
In completely unrelated news, the commits to my favorite project have increased substantially over the last few months.
I believe everything in the article. Fuzzing wouldn't have found these issues. Static analysis wouldn't have found these issues. I've been running those for decades. In 2026, they are completely inadequate for any project which has publicly available source code.
Even in situations with an overweight of false reports, if the LLM identify 1000 potential issues, then that is a manageable and finite set to sift through. It is a lot better than "here is the entire code base, have a look around for yourself".
Granted security researchers have good educated guesses for where one might typically find bugs, so the set is not quite "everything".
A counter point to that is that rare bugs hiding in blindspots not typically investigated by security researchers, can go undetected for a long time.
I expect to see an enormous wave of security bugs uncovered in the coming months
I want to know how many have already been uncovered and not reported. The black hats have to be using these tools too. Are there any broad statistics about zero day prevalence that would show a trend in an increase in discovery of new exploits?
Nobody with a decent security posture runs NFS, ever. Finding flaws in NFS "security" (especially on Linux) has always been shooting fish in a barrel with dynamite sticks. I'm amazed that the bug Claude coughed up was this subtle; I would have expected something much more obvious.
I'd be more interested if Claude coughed up stuff in the Linux scheduler or memory management subsystems. Those are very dangerous places to have bugs and have had lots of eyes staring at them for a long time.
The original talk is found here: https://www.youtube.com/watch?v=1sd26pWhfmg
Finds a SQL bug for Ghost.
About the actual NFS semantics, wonder why server should send information about current lock owner! Makes sense only in debug mode or when troubleshooting, could very well be a new NFS OP to get lock info.
I don't think the age of the bug is necessarily of relevance here; how much was this path tested (from a security PoV)? Also, somehow this bug reminded me of Antithesis, and specifically a couple of bugs discovered in etcd.