Live data from Hacker News

Claude Code Found a Linux Vulnerability Hidden for 23 Years

mtlynch.io

191–200 of 303 posts

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

#191

Earlier quoted context omitted.

"No one bothered to look" is how most vulnerabilities work. Systems development produces code artifacts with compounding complexity; it is extraordinarily difficult to keep up with it manually, as you know. A solution to that problem is big news. Static analyzers will find all possible copies of unbounded data into smaller buffers (especially when the size of the target buffer is easily deduced). It will then report…

With a capable static analyzer that is not true. In many common cases they can deduce the possible ranges of values based on branching checks along the data flow path, and if that range falls within the buffer then it does not report it.

Be specific. Which analyzer are you talking about and which specific targets are you saying they were successful at?

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

#192

Earlier quoted context omitted.

Claude and Codex pro/max subs aren't supposed to be used for commercial/enterprise development so its not really an option for execs in enterprise. They need to take into account API costs. At my F500 company execs are very wary of the costs of most of these tools and its always top of mind. We have dashboards and gather tons of internal metrics on which tools devs are using and how much they are costing.

No, I think that’s wrong. They aren’t supposed to be put behind a service, but they can certainly be used to write professional products/ products for the enterprise.

[deleted]

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

#194
post #154

Earlier quoted context omitted.

That's not what is happening right now. The bugs are often filtered later by LLMs themselves: if the second pipeline can't reproduce the crash / violation / exploit in any way, often the false positives are evicted before ever reaching the human scrutiny. Checking if a real vulnerability can be triggered is a trivial task compared to finding one, so this second pipeline has an almost 100% success rate from the POV: i…

> Checking if a real vulnerability can be triggered is a trivial task compared to finding one Have you ever tried to write PoC for any CVE? This statement is wrong. Sometimes bug may exist but be impossible to trigger/exploit. So it is not trivial at all.

oh no. Antirez doesn't know anything about C, CVE's, networking, the linux kernel. Wonder where that leaves most of us.

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

#195
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.

[deleted]

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

#196

Earlier quoted context omitted.

Claude and Codex pro/max subs aren't supposed to be used for commercial/enterprise development so its not really an option for execs in enterprise. They need to take into account API costs. At my F500 company execs are very wary of the costs of most of these tools and its always top of mind. We have dashboards and gather tons of internal metrics on which tools devs are using and how much they are costing.

Are they also measuring productivity? Measuring only token costs is like looking only at grocery spend but not the full receipt: you don’t know whether you fed your family for a week or for only a day.

I'm not one of those execs, I'm just echoing what they tell us from those I've talked to who manage these dashboards and worry about this. I do think measuring productivity is not very clear-cut especially with these tools.

They do "attempt" to measure productivity. But they also just see large dollar amounts on AI costs and get wary.

My company is also wary of going all in with any one tool or company due to how quickly stuff changes. So far they've been trying to pool our costs across all tools together and give us an "honor system" limit we should try not to go above per month until we do commit to one suite of tools.

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

#198
post #169

Earlier quoted context omitted.

That's not what is happening right now. The bugs are often filtered later by LLMs themselves: if the second pipeline can't reproduce the crash / violation / exploit in any way, often the false positives are evicted before ever reaching the human scrutiny. Checking if a real vulnerability can be triggered is a trivial task compared to finding one, so this second pipeline has an almost 100% success rate from the POV: i…

> This is expected in the normal population A lot of people regardless of technical ability have strong opinions about what LLMs are/are-not. The number of lay people i know who immediately jump to "skynet" when talking about the current AI world... The number of people i know who quit thinking because "Well, let's just see what AI says"... A (big) part of the conversation re: "AI" has to be "who are the people behin…

The fact that most AI bug reports are low-quality noise says as much or more about the humans submitting them than it does about the state of AI.

As others have said, there are multiple stages to bug reports and CVEs.

1. Discover the bug

2. Verify the bug

You get the most false positives at step one. Most of these will be eliminated at step 2.

3. Isolate the bug

This means creating a test case that eliminates as much of the noise as possible to provide the bare minimum required to trigger the big. This will greatly aid in debugging. Doing step 2 again is implied.

4. Report the bug

Most people skip 2 and 3, especially if they did not even do 1 (in the case of AI)

But you can have AI provide all 4 to achieve high quality bug reports.

In the case of a CVE, you have a step 5.

5 - Exploit the bug

But you do not have to do step 5 to get to step 2. And that is the step that eliminates most of the noise.

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

#199

Earlier quoted context omitted.

First you have to figure out HOW to measure productivity.

(Output / input), both of which are usually measured in money. If you can measure both of those things--and you have bigger problems if your finance department can't--it logically follows that you can measure productivity.

Measuring strictly in terms of money per unit time over a small enough timeframe is difficult because not all tasks directly result in immediately observed results.

There are tasks worked on at large enterprises that have 5+ year horizons, and those can't all immediately be tracked in terms of monetary gain that can be correlated with AI usage. We've barely even had AI as a daily tool used for development for a few years.

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

#200
post #181
post #154

Earlier quoted context omitted.

> Checking if a real vulnerability can be triggered is a trivial task compared to finding one Have you ever tried to write PoC for any CVE? This statement is wrong. Sometimes bug may exist but be impossible to trigger/exploit. So it is not trivial at all.

I'm tickled at the idea of asking antirez [1] if he's ever written a PoC for a CVE. [1] https://en.wikipedia.org/wiki/Salvatore_Sanfilippo

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.
Post reply on HN