16 ms·

Significant raise of reports

313 points by stratos123 7mo ago

stratos123 7mo ago
"On the kernel security list we've seen a huge bump of reports. We were between 2 and 3 per week maybe two years ago, then reached probably 10 a week over the last year with the only difference being only AI slop, and now since the beginning of the year we're around 5-10 per day depending on the days (fridays and tuesdays seem the worst). Now most of these reports are correct, to the point that we had to bring in more maintainers to help us."
- sevg 7mo ago
  Is there a reason you’ve copy pasted the first paragraph from the link? It doesn’t add anything to the discussion, and also doesn’t help as a tl;dr because it’s literally the first paragraph. Genuine question!
  - stratos123 7mo ago
    The actual title is pretty unclear ("Significant Raise of Reports" of what?), so I considered replacing it by some of this excerpt, but HN rules say not to editorialize titles. Hence I put it into the `text` field, which I thought would be the body, but actually just gets posted as a comment.
nayroclade 7mo ago
> I don't know how long this pace will last. I suspect that bugs are reported faster than they are written, so we could in fact be purging a long backlog Hopefully these same tools will also help catch security bugs at the point they're written. Maybe one day we'll reach a point where the discovery of new, live vulnerabilities is extremely rare?
- Sharlin 7mo ago
  Around 70% of security vulnerabilities are about memory safety and only exist because software is written in C and C++. Because most vulnerabilities are in newly written code, Google has found that simply starting writing new code in Rust (rather than trying to rewrite existing codebases) quickly brings the number of found vulnerabilities down drastically.
  - noosphr 7mo ago
    And to a good approximation all real world Rust uses unsafe everywhere. So we now have a new code base in an undefined language which still has memory bugs. This is progress.
    - kibwen 7mo ago
      No, this is false. For Rust codebases that aren't doing high-peformance data structures, C interop, or bare-metal stuff, it's typical to write no unsafe code at all. I'm not sure who told you otherwise, but they have no idea what they're talking about.
      - crote 7mo ago
        It's the classic "misunderstanding" that UB or buggy unsafe code could in theory corrupt any part of your running application (which is technically true), and interpreting this to mean that any codebase with at least one instance of UB / buggy unsafe code (which is ~100% of codebases) is safety-wise equivalent to a codebase with zero safety check - as all the safety checks are obviously complete lies and therefore pointless time-wasters. Which obviously isn't how it works in practice, just like how C doesn't delete all the files on your computer when your program contains any form of signed integer overflow, even though it technically could as that is totally allowed according to the language spec.
        zozbot234 7mo ago
        If you're talking about Rust codebases, I'm pretty sure that writing sound unsafe code is at least feasible. It's not easy, and it should be avoided if at all possible, but saying that 100% of those codebases are unsound is pessimistic. One feasible approach is to use "storytelling" as described here: https://www.ralfj.de/blog/2026/03/13/inline-asm.html https://www.ralfj.de/blog/2026/03/13/inline-asm.html That's talking about inline assembly, but in principle any other unsafe feature could be similarly modeled.
- deleted 7mo ago
  [deleted]
glimshe 7mo ago
The last paragraph is interesting: "Overall I think we're going to see a much higher quality of software, ironically around the same level than before 2000 when the net became usable by everyone to download fixes. When the software had to be pressed to CDs or written to millions of floppies, it had to survive an amazing quantity of tests that are mostly neglected nowadays since updates are easy to distribute." Was software made before 2000 better? And, if so, was it because of better testing or lower complexity?
- deleted 7mo ago
  [deleted]
- psyklic 7mo ago
  > Was software made before 2000 better? At the time of release, yes. They had to ensure the software worked before printing CDs and floppies. Nowadays they release buggy versions that users essentially test for them.
  - dspillett 7mo ago
    Also in terms of security, there was generally a much smaller potential attack surface and those surfaces were harder to reach because we were much less constantly connected.
    - PaulHoule 7mo ago
      But there was much less awareness of buffer overflows and none of the countermeasures that are widespread today. It was almost defining of the Win95 era that applications (eg. Word) frequently crashed because of improper and unsafe memory management.
    - armchairhacker 7mo ago
      I remember opening a webpage and being hacked seemed more likely. Adobe Flash and Java had more vulnerabilities and weaker (if any) sandboxes than JavaScript.
    - 7mo ago
themafia 7mo ago
An AI enthusiast having a breathless and predictive position on the future of the technology? No way! It's almost like Wall Street is about to sour on the whole stack and there is a concerted effort to artificially push these views into the conversation to get people on board. Then again, I'm a known crank and aggressive cynic, but you never really see any gathered data backing these points up.
- dieulot 7mo ago
  Could you back up your assertion that Willy Tarreau — who used to maintain the Linux kernel — is “an AI enthusiast”? I can’t find anything about it.
  - logicprog 7mo ago
    Anyone who says anything good about AI must be an AI shill from the start, not someone who is genuinely observing reality or had their mind changed, don't you know?
  - cdavid 7mo ago
    Also one of the initial creator of haproxy, a well known reverse proxy. To imply somebody like as a simple "AI shill" is just ignorant.
- logicprog 7mo ago
  > but you never really see any gathered data backing these points up. https://www.anthropic.com/news/mozilla-firefox-security https://www.anthropic.com/news/mozilla-firefox-security ?
- PKop 7mo ago
  Sort of a tautology to just assert that someone saying good things about AI is an AI enthusiast and therefore their opinion should be dismissed. He also happens to have been a kernel maintainer, his experience as he's describing it should count for something.
  - 7mo ago
Shank 7mo ago
Important to note that this is a comment on this article: https://lwn.net/Articles/1065586/ https://lwn.net/Articles/1065586/.
- JumpCrisscross 7mo ago
  “Reversing was already mostly a speed-bump even for entry-level teams, who lift binaries into IR or decompile them all the way back to source. Agents can do this too, but they can also reason directly from assembly. If you want a problem better suited to LLMs than bug hunting, program translation is a good place to start.” Huh. Direct debugging, in assembly. At that point, why not jump down to machine code?
  - deleted 7mo ago
    [deleted]
  - bombcar 7mo ago
    Decompiled assembly is basically machine code; without recreating the macros that make assembly "high level" you're as close to machine code as you're going to get unless you're trying to exploit the CPU itself.
  - sharifhsn 7mo ago
    For the purposes of debugging, assembly is machine code, just with some nice constructs to make it easier to read. Transpiling between assembly and machine code is mostly a find-and-replace exercise, not like the advanced reasoning involved in proper compilation.
    - IsTom 7mo ago
      On x86/x64/variable instruction length architectures this isn't always the case. You can jump in middle of an instruction to get a different instruction. It can be used to obfuscate code.
  - throawayonthe 7mo ago
    i think they aren't saying "it's more effective to debug at assembly level" but just that LLMs might be less dependent on decompilation/RE that tries to recreate high level code (the context is specifically about closed-source programs)
adverbly 7mo ago
Anecdotally, I've been seeing a higher rate of CVEs tracked by a few dependabot projects. Seems supported by this as well: https://www.first.org/blog/20260211-vulnerability-forecast-2026 https://www.first.org/blog/20260211-vulnerability-forecast-2... Interesting that it's been higher than forecast since 2023. Personally I'd expect that trend to continue given that LLMs both increase bugs written as well as bugs discovered.
siruwastaken 7mo ago
It's interesting to hear from people directly in the thick of it that these bug reports are apparently gaining value and are no longer just slop. Maybe there is hope for a world where AI helps create bug free software and doesn't just overload maintainers.
HAMSHAMA 7mo ago
Probably related to this (genuinely interesting) talk given by an entropic researcher https://youtu.be/1sd26pWhfmg?si=j2AWyCfbNbOxU4MF https://youtu.be/1sd26pWhfmg?si=j2AWyCfbNbOxU4MF
- svat 7mo ago
  To clarify, the talk is by an Anthropic researcher, though given the subject of LLMs, "entropic researcher" also makes some kind of sense.
throwatdem12311 7mo ago
Reports being written faster than bugs being created? Better quality software than before the 2000s? Oh my sweet summer child. This is some seriously delusional cope from someone who drank the entire jug of kool-aid. I’d love to be proven wrong but the current trajectory is pretty plain as day from current outcomes. Everything is getting worse, and everyone is getting overwhelmed and we are under attack even more and the attacks are getting substantially more sophisticated and the blast radius is much bigger.
0x3f 7mo ago
Why don't we just pagerank github contributors? Merged PRs approved by other quality contributors improves rank. New PRs tagged by a bot with the rank of the submitter. Add more scoring features (account age? employer?) as desired.
- SoftTalker 7mo ago
  It will be gamed, just as pagerank was.
  - cafebabbe 7mo ago
    Not by everyone, so that would be better than nothing.
    - bastawhiz 7mo ago
      Excited to have to do SEM for my GitHub profile so that people will read my pull requests
      - 0x3f 7mo ago
        Well it's all going to be social credit one day. Might as well get in practice early.
  - 0x3f 7mo ago
    Of course, but killing the 80% of low hanging fruit is already valuable. The rest is an arms race like always.
piinbinary 7mo ago
I'd be very curious to know what class of vulnerability these tend to be (buffer overrun, use after free, misset execute permissions?), and if, armed with that knowledge, a deterministic tool could reliably find or prevent all such vulnerabilities. Can linters find these? Perhaps fuzzing? If code was written in a more modern language, is it sill likely that these bugs would have happened?
- bri3d 7mo ago
  > Can linters find these? Perhaps fuzzing? That's what syzbot / syzkaller does, as mentioned in the article, with somewhat similar results to the AI-fuzzing that they've been experiencing recently. The issue that Linux maintainers have in general is that there are so many of these "strict correctness and safety" bugs in the Linux codebase that they can't fix them all at once, and they have no good mechanism to triage "which of these bugs is accessible to create an exploit." This is also the argument by which most of their bugs become CVEs; in lieu of the capability to determine whether a correctness bug is reachable by an attacker, any bug could be an exploit, and their stance is that it's too much work to decide which is which.
  - tptacek 7mo ago
    It's a bigger deal than that. Academically, syzkaller is just a very well orchestrated fuzzer, producing random pathological inputs to system calls, detecting crashes, and then producing reproductions. Syzkaller doesn't "know" what it's found, and a substantial fraction of what it finds are "just" crashers that won't ever be weaponizable. An LLM agent finding vulnerabilities is an implicit search process over a corpus of inferred vulnerability patterns and inferred program structure. It's stochastic static program analysis (until you have the agent start testing). It's generating (and potentially verifying) hypotheses about actual vulnerabilities in the code. That distinction is mostly academic. The bigger deal is: syzkaller crashes are part of the corpora of inputs agents will use to verify hypotheses about how to exploit Linux. It's an open secret that there are significant vulnerabilities encoded in the (mostly public!) corpus of syzbot crash reproductions; nobody has time to fish them out. But agents do, and have the added advantage of being able to quickly place a crash reproduction in the inferred context of kernel internals.
3form 7mo ago
>people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx" The problem is that the very same tools, I expect, are behind the supply chain attacks that seem to be particularly notorious recently. No matter where you turn, there's an edge to cut you on that one.
devcraft_ai 7mo ago
[flagged]
chromacity 7mo ago
> people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx" Linux devs keep making that point, but I really don't understand why they expect the world to embrace that thinking. You don't need to care about the vast majority of software defects in Linux, save for the once-in-a-decade filesystem corruption bug. In fact, there is an incentive not to upgrade when things are working, because it takes effort to familiarize yourself with new features, decide what should be enabled and what should be disabled, etc. And while the Linux kernel takes compatibility seriously, most distros do not and introduce compatibility-breaking changes with regularity. Binary compatibility is non-existent. Source compatibility is a crapshoot. In contrast, you absolutely need to care about security bugs that allow people to run code on your system. So of course people want to treat security bugs differently from everything else and prioritize them.
- IshKebab 7mo ago
  Yeah that attitude really makes no sense, and I don't see why AI finding security bugs would make people "finally understand". I suspect it's just an excuse for Linux's generally poor security track record.
  - tptacek 7mo ago
    Everything has a poor security track record. That's the point.
    - akerl_ 7mo ago
      Well, except OpenBSD. They’ve only had two vulns in forever.
      - tptacek 7mo ago
        You mean "in the default install, in a heck of a long time". :)
      - cperciva 7mo ago
psychoslave 7mo ago
>software that used to follow the "release-then-go-back-to-cave" model will have to change to start dealing with maintenance for real, or to just stop being proposed to the world as the ultimate-tool-for-this-and-that because every piece of software becomes a target. Actually, some software are running the water-heater/heat-pump system in my basement. There is a small blue light screen, it keeps logs of consumed electricity/produced heat and can make small histograms. Of course there is a smart option to make it internet connected. The kind of functionality I’m glad it’s disabled by default and not enforced to be able to operate. If possible, I’ll never upgrade it. Release then go back to the cave has definitely its place in many actual physical product in the world. I’ll deal with enough WTF software security in my daily job during my career. Sparing some cognitive load of whatever appliance being turned into a brick because the company that produced it or some script-kiddy-on-ai-steroid decided it was desirable to do so, that’s more time to do whatever other thing cosmos allows to explore.
- mentalgear 7mo ago
  There's an anecdote I remember reading somewhere: When an 'embedded systems' engineer was to present a web-based product they were tasked to build, the managers/reviewers were puzzled they couldn't find any bugs. Asked about this, the engineer replied: "I didn't know that was an option". Definitely a different mindset/toolset is required when it comes to building systems that have to be working autonomously without "quick fixes" from the web.
  - radlad 7mo ago
    Yes but I would push back a little on the idea that you simply put yourself in a "mindset of writing bug-free code." Simpler code has fewer bugs. Embedded code tends to be simpler and more targeted in its role. Of course, putting yourself in the mindset of writing simpler code is great too - if you have the time to do so, and the problem you are solving is itself sufficiently simple.
    - SoftTalker 7mo ago
      Embedded code is also simpler because it has to be. When you are confined to a microcontroller, there isn't room for bloated app frameworks, hundreds of NPM packages, etc.
tyre 7mo ago
I wish they wouldn’t call it “AI slop” before acknowledging that most of the bugs are correct. Let’s bring a bit of nuance between mindless drivel (e.g. LinkedIn influencing posts, spammed issues that are LLMs making mistakes) vs using LLMs to find/build useful things.
- _se 7mo ago
  It can be correct and slop at the same time. The reporter could have reported it in a way that makes it clear a human reviewed and cared about the report. Slop is a function of how the information is presented and how the tools are used. People don't care if you use LLMs if they don't tell you can use them, they care when you send them a bunch of bullshit with 5% of value buried inside it. If you're reading something and you can tell an LLM wrote it, you should be upset. It means the author doesn't give a fuck.
  - tptacek 7mo ago
    No it can't. These aren't "Show HN" posts about new programs people have conjured with Claude. They're either vulnerabilities or they're not. There's no such thing as a "slop vulnerability". The people who exploit those vulnerabilities do not care how much earlier reporters "gave a fuck" about their report. This is in the linked story: they're seeing increased numbers of duplicate findings, meaning, whatever valid bugs showboating LLM-enabled Good Samaritans are finding, quiet LLM-enabled attackers are also finding. People doing software security are going to need to get over the LLM agent snootiness real quick. Everyone else can keep being snooty! But not here.
    - parliament32 7mo ago
      > There's no such thing as a "slop vulnerability" https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/ https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-s... See the list at the bottom of the post for examples.
      - tptacek 7mo ago
ori_b 7mo ago
Or we can stop putting everything on the internet as a vector for enforced enshittification.
michelwague43 7mo ago
[dead]
amiga386 7mo ago
This is "the bomber will always get through" mentality for the modern era. You will invent air defences. You will write fewer bugs. You will leave code that doesn't have bugs alone, so it gains no more bugs. You will build software that finds bugs as easily as you think "enemies" find bugs, and you'll run it before you release your code. What's the saying? Given many eyes, all bugs are shallow? Well, here are some more eyes.
michelwague 7mo ago
this is what i'm seeing on a micro scale. i pointed a code-davinci-002 model at my own repo and it found a subtle off-by-
mirax 7mo ago
This really comforts me :) I'm looking forward to a more secure and private IT future.
sigbottle 7mo ago
I'm actually curious about AI progress: There's no way the AI is a priori understanding codebases with millions of LoC now. We've tried that already, it failed. What it is doing now is setting up its own extremely powerful test harnesses and getting the information and testing it efficiently. Sure, its semantic search is already strong, but the real lesson that we've learned from 2025 is that tooling is way more powerful. That's cool! I've always wanted to learn how kernel devs properly test stuff reliably but it seemed hard. As someone who's dabbled in kernel dev for his job. Like real variable hardware, and not just manual testing shit. Honestly, AI has only helped me become a better SWE because no one else has the time or patience to teach me.
- tptacek 7mo ago
  What do you mean "a priori understanding codebases"? Quantify it and let's test specifically what you mean. Linux is huge.
  - par1970 7mo ago
    > What do you mean "a priori understanding codebases"? I took him to be distinguishing between (1) just reading the code/docs and reasoning about it, and (2) that + crafting and running tests.
    - tptacek 7mo ago
      I don't think that's it; both reading the code and running tests are a posteriori capabilities.
      - par1970 7mo ago
        Yeah, maybe you are right. But is doing math and reasoning about Turing machines a priori? If so, then it seems plausible to me that reasoning about a codebase (without running it) is also ‘a priori’.
      - sigbottle 7mo ago
        No you're right. I initially thought you were wrong but it is sus. My intuition for a priori cut something along the lines of, "Even if you had the entire source code in your head at once, there's limits to reasoning about it". Computability is one hard result. You also have to interact with the real world on a wide variety of hardware systems, or even just a wide variety of systems if you create an API - how do you reason past the abstraction boundary reliably without actually having tests and interacting with systems and getting feedback? Not really possible unless LLM's control everything. More philosophical questions (such as "is our 'correct' actually the right thing?") we grant the easy case that everybody's in consensus - the "easier" problems show up either way. But getting to the point of "understanding in principle every piece of linux" is pretty undefined and practically doesn't seem possible for a singular LLM or a human. This also seems really hairy for smuggling in whatever implicit premises you want to swing the issue either way. But personally I (and many other people) have seen late 2025 models get extremely good, and that precisely is because they actually started doing deep tooling and like, actually running and testing their code. I was not getting nearly as much value out of them (still a decent amount of value!) prior to the tooling explosion, not even MCPs were good. It was when they actually started aggressively spawning subshells and executing live tests. But I guess using a priori/posterioi isn't really a useful split here?
motbus3 7mo ago
The slapocalipse is here, but I would propose the idea that open source maintainer get free access to AI tools from these big companies, so at least they can aggregate the problems and have some level of automation of the process. For me, this seems something that would make sense for all dev community to push for.
- functional_dev 7mo ago
  agreed, attackers can use these AI tools to scan open source code and find bugs very fast... if project maintainers do not have access to such tools, it because an ufair fight
  - motbus3 7mo ago
    Exactly. The rate of acceptance right now is low. Maybe less than 10% and most will not be relevant. Also, if they can use it to categorise, validate and test it why not? If they have 100 new bugs, but all useless ones already checked and close life would be almost normal again. Using llm for things that require knowledge is sketchy and unreliable, but having fixed pipeline checks that runs few hooks, maybe some automated scripts, add context, link bugs, create clear versions of the conversation... That's ok! We see many companies stumbling on the llm problems when the code get to big or too messy, and that will be it, imho. But using those tools as small quick gains is here to stay.
jcalvinowens 7mo ago
> I suspect that bugs are reported faster than they are written, so we could in fact be purging a long backlog (and I hope so). It's hard for me to imagine how this wouldn't be true. This isn't the "new normal", everyone is just running it into the ground and wringing every drop they can out of it right now. It would be interesting to "backtest" how much higher the rate of vulnerability discovery would have been if all these new vulnerabilities were discovered in near real time as they were created, since that would be more predictive of the "new normal", in my opinion. I suspect it's not very significant: we're flushing a 20+ year backlog, and generally the rate at which vulnerabilities are created is lower today.
- TacticalCoder 7mo ago
  > I suspect it's not very significant: we're flushing a 20+ year backlog, and generally the rate at which vulnerabilities are created is lower today. The thing is: if these new AI tools can find a backlog of old bugs, these tools can very obviously be used on code that hasn't been pushed yet. And they'll find potential bugs there too. And so the rate at which new vulns are created is soon going to be even much, much, much lower. Now of course I'm talking about serious projects like the Linux kernel in TFA: real stuff that powers the real-world. If we're talking about OpenClaw who decided to launch a startup based on a "Write me a clone of MySpace but with a Web design from the 2020s" prompt, then all bets are off. The nice thing with using AI tools to find bugs is that there's not much ambiguity: a bug, if proven to be a bug, has to be squashed. It doesn't matter how it was found: even the AI doubters can accept there's a bug and that something has to be done about it. Using AI tools to fix bugs in the Linux kernel is IMO much more impressive than "Write me the 10 000th MySpace clone but using a Web design from the 2020s".
imenani 6mo ago
With the benefit of hindsight, perhaps much of this was Claude Mythos? The model was deployed internally since Feb

313 points by stratos123 7mo ago

"On the kernel security list we've seen a huge bump of reports. We were between 2 and 3 per week maybe two years ago, then reached probably 10 a week over the last year with the only difference being only AI slop, and now since the beginning of the year we're around 5-10 per day depending on the days (fridays and tuesdays seem the worst). Now most of these reports are correct, to the point that we had to bring in more maintainers to help us."

sevg 7mo ago
Is there a reason you’ve copy pasted the first paragraph from the link? It doesn’t add anything to the discussion, and also doesn’t help as a tl;dr because it’s literally the first paragraph. Genuine question!
- stratos123 7mo ago
  The actual title is pretty unclear ("Significant Raise of Reports" of what?), so I considered replacing it by some of this excerpt, but HN rules say not to editorialize titles. Hence I put it into the `text` field, which I thought would be the body, but actually just gets posted as a comment.

nayroclade 7mo ago

> I don't know how long this pace will last. I suspect that bugs are reported faster than they are written, so we could in fact be purging a long backlog Hopefully these same tools will also help catch security bugs at the point they're written. Maybe one day we'll reach a point where the discovery of new, live vulnerabilities is extremely rare?

Sharlin 7mo ago
Around 70% of security vulnerabilities are about memory safety and only exist because software is written in C and C++. Because most vulnerabilities are in newly written code, Google has found that simply starting writing new code in Rust (rather than trying to rewrite existing codebases) quickly brings the number of found vulnerabilities down drastically.
- noosphr 7mo ago
  And to a good approximation all real world Rust uses unsafe everywhere. So we now have a new code base in an undefined language which still has memory bugs. This is progress.
  - kibwen 7mo ago
    No, this is false. For Rust codebases that aren't doing high-peformance data structures, C interop, or bare-metal stuff, it's typical to write no unsafe code at all. I'm not sure who told you otherwise, but they have no idea what they're talking about.
    - crote 7mo ago
      It's the classic "misunderstanding" that UB or buggy unsafe code could in theory corrupt any part of your running application (which is technically true), and interpreting this to mean that any codebase with at least one instance of UB / buggy unsafe code (which is ~100% of codebases) is safety-wise equivalent to a codebase with zero safety check - as all the safety checks are obviously complete lies and therefore pointless time-wasters. Which obviously isn't how it works in practice, just like how C doesn't delete all the files on your computer when your program contains any form of signed integer overflow, even though it technically could as that is totally allowed according to the language spec.
      - zozbot234 7mo ago
        If you're talking about Rust codebases, I'm pretty sure that writing sound unsafe code is at least feasible. It's not easy, and it should be avoided if at all possible, but saying that 100% of those codebases are unsound is pessimistic. One feasible approach is to use "storytelling" as described here: https://www.ralfj.de/blog/2026/03/13/inline-asm.html https://www.ralfj.de/blog/2026/03/13/inline-asm.html That's talking about inline assembly, but in principle any other unsafe feature could be similarly modeled.
deleted 7mo ago
[deleted]

glimshe 7mo ago

The last paragraph is interesting: "Overall I think we're going to see a much higher quality of software, ironically around the same level than before 2000 when the net became usable by everyone to download fixes. When the software had to be pressed to CDs or written to millions of floppies, it had to survive an amazing quantity of tests that are mostly neglected nowadays since updates are easy to distribute." Was software made before 2000 better? And, if so, was it because of better testing or lower complexity?

deleted 7mo ago
[deleted]
psyklic 7mo ago
> Was software made before 2000 better? At the time of release, yes. They had to ensure the software worked before printing CDs and floppies. Nowadays they release buggy versions that users essentially test for them.
- dspillett 7mo ago
  Also in terms of security, there was generally a much smaller potential attack surface and those surfaces were harder to reach because we were much less constantly connected.
  - PaulHoule 7mo ago
    But there was much less awareness of buffer overflows and none of the countermeasures that are widespread today. It was almost defining of the Win95 era that applications (eg. Word) frequently crashed because of improper and unsafe memory management.
  - armchairhacker 7mo ago
    I remember opening a webpage and being hacked seemed more likely. Adobe Flash and Java had more vulnerabilities and weaker (if any) sandboxes than JavaScript.
  - 7mo ago

themafia 7mo ago

An AI enthusiast having a breathless and predictive position on the future of the technology? No way! It's almost like Wall Street is about to sour on the whole stack and there is a concerted effort to artificially push these views into the conversation to get people on board. Then again, I'm a known crank and aggressive cynic, but you never really see any gathered data backing these points up.

dieulot 7mo ago
Could you back up your assertion that Willy Tarreau — who used to maintain the Linux kernel — is “an AI enthusiast”? I can’t find anything about it.
- logicprog 7mo ago
  Anyone who says anything good about AI must be an AI shill from the start, not someone who is genuinely observing reality or had their mind changed, don't you know?
- cdavid 7mo ago
  Also one of the initial creator of haproxy, a well known reverse proxy. To imply somebody like as a simple "AI shill" is just ignorant.
logicprog 7mo ago
> but you never really see any gathered data backing these points up. https://www.anthropic.com/news/mozilla-firefox-security https://www.anthropic.com/news/mozilla-firefox-security ?
PKop 7mo ago
Sort of a tautology to just assert that someone saying good things about AI is an AI enthusiast and therefore their opinion should be dismissed. He also happens to have been a kernel maintainer, his experience as he's describing it should count for something.
- 7mo ago

Shank 7mo ago

Important to note that this is a comment on this article: https://lwn.net/Articles/1065586/ https://lwn.net/Articles/1065586/.

JumpCrisscross 7mo ago
“Reversing was already mostly a speed-bump even for entry-level teams, who lift binaries into IR or decompile them all the way back to source. Agents can do this too, but they can also reason directly from assembly. If you want a problem better suited to LLMs than bug hunting, program translation is a good place to start.” Huh. Direct debugging, in assembly. At that point, why not jump down to machine code?
- deleted 7mo ago
  [deleted]
- bombcar 7mo ago
  Decompiled assembly is basically machine code; without recreating the macros that make assembly "high level" you're as close to machine code as you're going to get unless you're trying to exploit the CPU itself.
- sharifhsn 7mo ago
  For the purposes of debugging, assembly is machine code, just with some nice constructs to make it easier to read. Transpiling between assembly and machine code is mostly a find-and-replace exercise, not like the advanced reasoning involved in proper compilation.
  - IsTom 7mo ago
    On x86/x64/variable instruction length architectures this isn't always the case. You can jump in middle of an instruction to get a different instruction. It can be used to obfuscate code.
- throawayonthe 7mo ago
  i think they aren't saying "it's more effective to debug at assembly level" but just that LLMs might be less dependent on decompilation/RE that tries to recreate high level code (the context is specifically about closed-source programs)

adverbly 7mo ago

Anecdotally, I've been seeing a higher rate of CVEs tracked by a few dependabot projects. Seems supported by this as well: https://www.first.org/blog/20260211-vulnerability-forecast-2026 https://www.first.org/blog/20260211-vulnerability-forecast-2... Interesting that it's been higher than forecast since 2023. Personally I'd expect that trend to continue given that LLMs both increase bugs written as well as bugs discovered.

siruwastaken 7mo ago

It's interesting to hear from people directly in the thick of it that these bug reports are apparently gaining value and are no longer just slop. Maybe there is hope for a world where AI helps create bug free software and doesn't just overload maintainers.

HAMSHAMA 7mo ago

Probably related to this (genuinely interesting) talk given by an entropic researcher https://youtu.be/1sd26pWhfmg?si=j2AWyCfbNbOxU4MF https://youtu.be/1sd26pWhfmg?si=j2AWyCfbNbOxU4MF

svat 7mo ago
To clarify, the talk is by an Anthropic researcher, though given the subject of LLMs, "entropic researcher" also makes some kind of sense.

throwatdem12311 7mo ago

Reports being written faster than bugs being created? Better quality software than before the 2000s? Oh my sweet summer child. This is some seriously delusional cope from someone who drank the entire jug of kool-aid. I’d love to be proven wrong but the current trajectory is pretty plain as day from current outcomes. Everything is getting worse, and everyone is getting overwhelmed and we are under attack even more and the attacks are getting substantially more sophisticated and the blast radius is much bigger.

0x3f 7mo ago

Why don't we just pagerank github contributors? Merged PRs approved by other quality contributors improves rank. New PRs tagged by a bot with the rank of the submitter. Add more scoring features (account age? employer?) as desired.

SoftTalker 7mo ago
It will be gamed, just as pagerank was.
- cafebabbe 7mo ago
  Not by everyone, so that would be better than nothing.
  - bastawhiz 7mo ago
    Excited to have to do SEM for my GitHub profile so that people will read my pull requests
    - 0x3f 7mo ago
      Well it's all going to be social credit one day. Might as well get in practice early.
- 0x3f 7mo ago
  Of course, but killing the 80% of low hanging fruit is already valuable. The rest is an arms race like always.

piinbinary 7mo ago

I'd be very curious to know what class of vulnerability these tend to be (buffer overrun, use after free, misset execute permissions?), and if, armed with that knowledge, a deterministic tool could reliably find or prevent all such vulnerabilities. Can linters find these? Perhaps fuzzing? If code was written in a more modern language, is it sill likely that these bugs would have happened?

bri3d 7mo ago
> Can linters find these? Perhaps fuzzing? That's what syzbot / syzkaller does, as mentioned in the article, with somewhat similar results to the AI-fuzzing that they've been experiencing recently. The issue that Linux maintainers have in general is that there are so many of these "strict correctness and safety" bugs in the Linux codebase that they can't fix them all at once, and they have no good mechanism to triage "which of these bugs is accessible to create an exploit." This is also the argument by which most of their bugs become CVEs; in lieu of the capability to determine whether a correctness bug is reachable by an attacker, any bug could be an exploit, and their stance is that it's too much work to decide which is which.
- tptacek 7mo ago
  It's a bigger deal than that. Academically, syzkaller is just a very well orchestrated fuzzer, producing random pathological inputs to system calls, detecting crashes, and then producing reproductions. Syzkaller doesn't "know" what it's found, and a substantial fraction of what it finds are "just" crashers that won't ever be weaponizable. An LLM agent finding vulnerabilities is an implicit search process over a corpus of inferred vulnerability patterns and inferred program structure. It's stochastic static program analysis (until you have the agent start testing). It's generating (and potentially verifying) hypotheses about actual vulnerabilities in the code. That distinction is mostly academic. The bigger deal is: syzkaller crashes are part of the corpora of inputs agents will use to verify hypotheses about how to exploit Linux. It's an open secret that there are significant vulnerabilities encoded in the (mostly public!) corpus of syzbot crash reproductions; nobody has time to fish them out. But agents do, and have the added advantage of being able to quickly place a crash reproduction in the inferred context of kernel internals.

3form 7mo ago

>people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx" The problem is that the very same tools, I expect, are behind the supply chain attacks that seem to be particularly notorious recently. No matter where you turn, there's an edge to cut you on that one.

devcraft_ai 7mo ago

[flagged]

chromacity 7mo ago

> people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx" Linux devs keep making that point, but I really don't understand why they expect the world to embrace that thinking. You don't need to care about the vast majority of software defects in Linux, save for the once-in-a-decade filesystem corruption bug. In fact, there is an incentive not to upgrade when things are working, because it takes effort to familiarize yourself with new features, decide what should be enabled and what should be disabled, etc. And while the Linux kernel takes compatibility seriously, most distros do not and introduce compatibility-breaking changes with regularity. Binary compatibility is non-existent. Source compatibility is a crapshoot. In contrast, you absolutely need to care about security bugs that allow people to run code on your system. So of course people want to treat security bugs differently from everything else and prioritize them.

IshKebab 7mo ago
Yeah that attitude really makes no sense, and I don't see why AI finding security bugs would make people "finally understand". I suspect it's just an excuse for Linux's generally poor security track record.
- tptacek 7mo ago
  Everything has a poor security track record. That's the point.
  - akerl_ 7mo ago
    Well, except OpenBSD. They’ve only had two vulns in forever.
    - tptacek 7mo ago
      You mean "in the default install, in a heck of a long time". :)
    - cperciva 7mo ago

psychoslave 7mo ago

>software that used to follow the "release-then-go-back-to-cave" model will have to change to start dealing with maintenance for real, or to just stop being proposed to the world as the ultimate-tool-for-this-and-that because every piece of software becomes a target. Actually, some software are running the water-heater/heat-pump system in my basement. There is a small blue light screen, it keeps logs of consumed electricity/produced heat and can make small histograms. Of course there is a smart option to make it internet connected. The kind of functionality I’m glad it’s disabled by default and not enforced to be able to operate. If possible, I’ll never upgrade it. Release then go back to the cave has definitely its place in many actual physical product in the world. I’ll deal with enough WTF software security in my daily job during my career. Sparing some cognitive load of whatever appliance being turned into a brick because the company that produced it or some script-kiddy-on-ai-steroid decided it was desirable to do so, that’s more time to do whatever other thing cosmos allows to explore.

mentalgear 7mo ago
There's an anecdote I remember reading somewhere: When an 'embedded systems' engineer was to present a web-based product they were tasked to build, the managers/reviewers were puzzled they couldn't find any bugs. Asked about this, the engineer replied: "I didn't know that was an option". Definitely a different mindset/toolset is required when it comes to building systems that have to be working autonomously without "quick fixes" from the web.
- radlad 7mo ago
  Yes but I would push back a little on the idea that you simply put yourself in a "mindset of writing bug-free code." Simpler code has fewer bugs. Embedded code tends to be simpler and more targeted in its role. Of course, putting yourself in the mindset of writing simpler code is great too - if you have the time to do so, and the problem you are solving is itself sufficiently simple.
  - SoftTalker 7mo ago
    Embedded code is also simpler because it has to be. When you are confined to a microcontroller, there isn't room for bloated app frameworks, hundreds of NPM packages, etc.

tyre 7mo ago

I wish they wouldn’t call it “AI slop” before acknowledging that most of the bugs are correct. Let’s bring a bit of nuance between mindless drivel (e.g. LinkedIn influencing posts, spammed issues that are LLMs making mistakes) vs using LLMs to find/build useful things.

_se 7mo ago
It can be correct and slop at the same time. The reporter could have reported it in a way that makes it clear a human reviewed and cared about the report. Slop is a function of how the information is presented and how the tools are used. People don't care if you use LLMs if they don't tell you can use them, they care when you send them a bunch of bullshit with 5% of value buried inside it. If you're reading something and you can tell an LLM wrote it, you should be upset. It means the author doesn't give a fuck.
- tptacek 7mo ago
  No it can't. These aren't "Show HN" posts about new programs people have conjured with Claude. They're either vulnerabilities or they're not. There's no such thing as a "slop vulnerability". The people who exploit those vulnerabilities do not care how much earlier reporters "gave a fuck" about their report. This is in the linked story: they're seeing increased numbers of duplicate findings, meaning, whatever valid bugs showboating LLM-enabled Good Samaritans are finding, quiet LLM-enabled attackers are also finding. People doing software security are going to need to get over the LLM agent snootiness real quick. Everyone else can keep being snooty! But not here.
  - parliament32 7mo ago
    > There's no such thing as a "slop vulnerability" https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/ https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-s... See the list at the bottom of the post for examples.
    - tptacek 7mo ago

ori_b 7mo ago

Or we can stop putting everything on the internet as a vector for enforced enshittification.

michelwague43 7mo ago

[dead]

amiga386 7mo ago

This is "the bomber will always get through" mentality for the modern era. You will invent air defences. You will write fewer bugs. You will leave code that doesn't have bugs alone, so it gains no more bugs. You will build software that finds bugs as easily as you think "enemies" find bugs, and you'll run it before you release your code. What's the saying? Given many eyes, all bugs are shallow? Well, here are some more eyes.

michelwague 7mo ago

this is what i'm seeing on a micro scale. i pointed a code-davinci-002 model at my own repo and it found a subtle off-by-

mirax 7mo ago

This really comforts me :) I'm looking forward to a more secure and private IT future.

sigbottle 7mo ago

I'm actually curious about AI progress: There's no way the AI is a priori understanding codebases with millions of LoC now. We've tried that already, it failed. What it is doing now is setting up its own extremely powerful test harnesses and getting the information and testing it efficiently. Sure, its semantic search is already strong, but the real lesson that we've learned from 2025 is that tooling is way more powerful. That's cool! I've always wanted to learn how kernel devs properly test stuff reliably but it seemed hard. As someone who's dabbled in kernel dev for his job. Like real variable hardware, and not just manual testing shit. Honestly, AI has only helped me become a better SWE because no one else has the time or patience to teach me.

tptacek 7mo ago
What do you mean "a priori understanding codebases"? Quantify it and let's test specifically what you mean. Linux is huge.
- par1970 7mo ago
  > What do you mean "a priori understanding codebases"? I took him to be distinguishing between (1) just reading the code/docs and reasoning about it, and (2) that + crafting and running tests.
  - tptacek 7mo ago
    I don't think that's it; both reading the code and running tests are a posteriori capabilities.
    - par1970 7mo ago
      Yeah, maybe you are right. But is doing math and reasoning about Turing machines a priori? If so, then it seems plausible to me that reasoning about a codebase (without running it) is also ‘a priori’.
    - sigbottle 7mo ago
      No you're right. I initially thought you were wrong but it is sus. My intuition for a priori cut something along the lines of, "Even if you had the entire source code in your head at once, there's limits to reasoning about it". Computability is one hard result. You also have to interact with the real world on a wide variety of hardware systems, or even just a wide variety of systems if you create an API - how do you reason past the abstraction boundary reliably without actually having tests and interacting with systems and getting feedback? Not really possible unless LLM's control everything. More philosophical questions (such as "is our 'correct' actually the right thing?") we grant the easy case that everybody's in consensus - the "easier" problems show up either way. But getting to the point of "understanding in principle every piece of linux" is pretty undefined and practically doesn't seem possible for a singular LLM or a human. This also seems really hairy for smuggling in whatever implicit premises you want to swing the issue either way. But personally I (and many other people) have seen late 2025 models get extremely good, and that precisely is because they actually started doing deep tooling and like, actually running and testing their code. I was not getting nearly as much value out of them (still a decent amount of value!) prior to the tooling explosion, not even MCPs were good. It was when they actually started aggressively spawning subshells and executing live tests. But I guess using a priori/posterioi isn't really a useful split here?

motbus3 7mo ago

The slapocalipse is here, but I would propose the idea that open source maintainer get free access to AI tools from these big companies, so at least they can aggregate the problems and have some level of automation of the process. For me, this seems something that would make sense for all dev community to push for.

functional_dev 7mo ago
agreed, attackers can use these AI tools to scan open source code and find bugs very fast... if project maintainers do not have access to such tools, it because an ufair fight
- motbus3 7mo ago
  Exactly. The rate of acceptance right now is low. Maybe less than 10% and most will not be relevant. Also, if they can use it to categorise, validate and test it why not? If they have 100 new bugs, but all useless ones already checked and close life would be almost normal again. Using llm for things that require knowledge is sketchy and unreliable, but having fixed pipeline checks that runs few hooks, maybe some automated scripts, add context, link bugs, create clear versions of the conversation... That's ok! We see many companies stumbling on the llm problems when the code get to big or too messy, and that will be it, imho. But using those tools as small quick gains is here to stay.

jcalvinowens 7mo ago

> I suspect that bugs are reported faster than they are written, so we could in fact be purging a long backlog (and I hope so). It's hard for me to imagine how this wouldn't be true. This isn't the "new normal", everyone is just running it into the ground and wringing every drop they can out of it right now. It would be interesting to "backtest" how much higher the rate of vulnerability discovery would have been if all these new vulnerabilities were discovered in near real time as they were created, since that would be more predictive of the "new normal", in my opinion. I suspect it's not very significant: we're flushing a 20+ year backlog, and generally the rate at which vulnerabilities are created is lower today.

TacticalCoder 7mo ago
> I suspect it's not very significant: we're flushing a 20+ year backlog, and generally the rate at which vulnerabilities are created is lower today. The thing is: if these new AI tools can find a backlog of old bugs, these tools can very obviously be used on code that hasn't been pushed yet. And they'll find potential bugs there too. And so the rate at which new vulns are created is soon going to be even much, much, much lower. Now of course I'm talking about serious projects like the Linux kernel in TFA: real stuff that powers the real-world. If we're talking about OpenClaw who decided to launch a startup based on a "Write me a clone of MySpace but with a Web design from the 2020s" prompt, then all bets are off. The nice thing with using AI tools to find bugs is that there's not much ambiguity: a bug, if proven to be a bug, has to be squashed. It doesn't matter how it was found: even the AI doubters can accept there's a bug and that something has to be done about it. Using AI tools to fix bugs in the Linux kernel is IMO much more impressive than "Write me the 10 000th MySpace clone but using a Web design from the 2020s".

imenani 6mo ago

With the benefit of hindsight, perhaps much of this was Claude Mythos? The model was deployed internally since Feb