Live data from Hacker News

Claude Code Found a Linux Vulnerability Hidden for 23 Years

mtlynch.io

261–270 of 303 posts

Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years

#261
post #172

This isn't surprising. What is not mentioned is that Claude Code also found one thousand false positive bugs, which developers spent three months to rule out.

What is with negativity against AI in YC? Can anyone point a finger of why this anti take is so prominent? We're living through the most revolutionary moment of software since it's its inception and the main thing that gets consistently upvoted is negativity, FUD and it doesn't work in this case, or it's all slop.

I think the anti-AI stance has been reversing on HN as tooling improves and people try it. It’s only been a little over a year since Claude Code was released, and 3 or 4 months since the models got really capable. People need time to adjust, even if I would expect devs to be more up-to-date than most.

People’s willingness to argue about technology they’ve barely used is always bewildering to me though.

Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years

#262
post #38
post #24

The title is a little misleading. It was Opus 4.6 (the model). You could discover this with some other coding agent harness. The other thing that bugs me and frankly I don't have the time to try it out myself, is that they did not compare to see if the same bug would have been found with GPT 5.4 or perhaps even an open source model. Without that, and for the reasons I posted above, while I am sure this is not the int…

OP here. I don't understand this critique. Carlini did use Claude Code directly. Claude Code used the Claude Opus 4.6 model, but I don't know why you'd consider it inaccurate to say Claude Code found it. GPT 5.4 might be capable of finding it as well, but the article never made any claims about whether non-Anthropic models could find it. If I wrote about achieving 10k QPS with a Go server, is the article misleading u…

Also, he did compare with earlier versions that, before 4.5, were dramatically worse at finding the same problems. There's even a graph. That seems to pretty solidly support the idea that this is "gain of function" as it were...

Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years

#263
post #260
post #225

Earlier quoted context omitted.

The “weapon” here is identifying vulnerabilities that were already present and exploitable by malicious actors?

A very shallow dismissal of my point. Is there no room for depth in your logical analysis? First of all, we don't know whether this particular bug was already being exploited in the wild. We do know that there is a community of experts looking at the Linux kernel and reporting bugs. Yet this bug had never been reported until now. So either nobody ever looked there (unlikely), or they did and didn't find it. Conversel…

> So either nobody ever looked there (unlikely), or they did and didn't find it.

Those aren't the only two options.

Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years

#264

Earlier quoted context omitted.

Remember Heartbleed in OpenSSL? That long predated LLMs, but same story: some bozo forgot how long something should/could be, and no one else bothered to check either.

I believe that once the OpenBSD team started cleaning up some of the other gross coding style stuff as part of their fork into LibreSSL that even fairly simplistic static analysis tools could spot the underlying bugs that caused heartbleed.

The bug that caused Heartbleed was extremely obvious: read a u16 out of a packet, copy that many bytes of the source packet into the reply packet. If someone put that code in front of you in isolation you would spot it instantly (if you know C). The problem --- this is hugely the case with most memory safety bugs --- is that it's buried under a mountain of OpenSSL TLS protocol handling details. You have to keep resident in your brain what all the inputs to the function are, and follow them through the code.

Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years

#265

Earlier quoted context omitted.

What's more useful is to have it attempt to not only find such bugs but prove them with a regression test. In Rust, for concurrency tests write e.g. Shuttle or Loom tests, etc.

It would be generally good if most code made setting up such tests as easy as possible, but in most corporate codebases this second step is gonna require a huge amount of refactoring or boilerplate crap to get the things interacting in the test env in an accurate, well-controlled way. You can quickly end up fighting to understand "is the bug not actually there, or is the attempt to repro it not working correctly?" (W…

That is an unfortunate case you described, but also, git gud and write tests in the first place so you don't need to refactor things down the road.

Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years

#266

Earlier quoted context omitted.

Intrinsa's PREfix static source code analyzer would model the execution of the C/C++ code to determine values which would cause a fault. IIRC they were using a C/C++ compiler front end from EDG to parse C/C++ code to a form they used for the simulation/analysis. see https://web.eecs.umich.edu/~weimerw/2006-655/reading/bush-pr... for more info. Microsoft bought Intrinsa several years ago.

I'm sure this is very interesting work, but can you tell me what targets they've been successful surfacing exploitable vulnerabilities on, and what the experience of generating that success looked like? I'm aware of the large literature on static analysis; I've spent most of my career in vulnerability research.

PREfix wasn't designed specifically for finding exploitable bugs - it was aimed somewhere in between Purify (runtime bug detection) and being a better lint.

One of the articles/papers I recall was that the big problem for PREfix when simulating the behaviour of code was the explosion in complexity if a given function had multiple paths through it (e.g. multiple if's/switch statements). PREfix had strategies to reduce the time spent in these highly complex functions.

Here's a 2004 link that discusses the limitations of PREfix's simulated analysis - https://www.microsoft.com/en-us/research/wp-content/uploads/...

The above article also talks about Microsoft's newer (for 2004) static analysis tools.

There's a Netscape engineer endorsement in a CNet article when they first released PREfix. see https://www.cnet.com/tech/tech-industry/component-bugs-stamp...

Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years

#268

Earlier quoted context omitted.

This happens over and over in these discussions. It doesn't matter who you're citing or who's talking. People are terrified and are reacting to news reflexively.

Hi! Loved your recent post about the new era of computer security, thanks.

Thank you! Glad you liked it.

Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years

#269
post #57

Pasting a big batch of new code and asking Claude "what have I forgotten? Where are the bugs?" is a very persuasive on-ramp for developers new to AI. It spots threading & distributed system bugs that would have taken hours to uncover before, and where there isn't any other easy tooling. I bet there's loads of cryptocurrency implementations being pored over right now - actual money on the table.

> It spots threading & distributed system bugs that would have taken hours to uncover before, and where there isn't any other easy tooling.

Go has a built in race detector which may be useful for this too: https://go.dev/doc/articles/race_detector

Unsure if it's suitable for inclusion in CI, but seems like something worth looking into for people using Go.

Re: Claude Code Found a Linux Vulnerability Hidden for 23 Years

#270
post #57

Pasting a big batch of new code and asking Claude "what have I forgotten? Where are the bugs?" is a very persuasive on-ramp for developers new to AI. It spots threading & distributed system bugs that would have taken hours to uncover before, and where there isn't any other easy tooling. I bet there's loads of cryptocurrency implementations being pored over right now - actual money on the table.

I like biasing it towards the fact that there is a bug, so it can't just say "no bugs! all good!" without looking into it very hard. Usually I ask something like this: "This code has a bug. Can you find it?" Sometimes I also tell it that "the bug is non-obvious" Which I've anecdotally found to have a higher rate of success than just asking for a spot check

> so it can't just say "no bugs! all good!"

If anyone, or anything, ever answers a question like that, you should stop asking it questions.

Post reply on HN