Claude Code Found a Linux Vulnerability Hidden for 23 Years
louwers
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?
mtlynch
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?
bazzargh
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
glhaynes
"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."
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.
mtlynch
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 requests 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.
simonw
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.
nelson
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?
louwers
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?
mtlynch
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?
bazzargh
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
glhaynes
"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."
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.
mtlynch
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 requests 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.
simonw
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.
nelson
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?
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?
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
…
"AI bug reports went from junk to legit overnight, says Linux kernel czar" - https://www.theregister.com/2026/03/26/greg_kroahhartman_ai_kernel/
I don't think this is true. This is believing that all output of the tool was necessary to reach the final state.
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.
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 requests 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.
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.
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?
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?
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
…
"AI bug reports went from junk to legit overnight, says Linux kernel czar" - https://www.theregister.com/2026/03/26/greg_kroahhartman_ai_kernel/
I don't think this is true. This is believing that all output of the tool was necessary to reach the final state.
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.
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 requests 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.
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.
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?