On Sun, Aug 30, 2026 at 10:45:41PM -0500, Aaron Rainbolt wrote: > I was going to respond with something along the lines of "yeah but then > the agent can just find a different vuln", but then looked at the > "From" address and realized I'm talking to the ext4 filesystem > maintainer :) so anything I have to say about how vulns work, you're > almost certainly well aware of already.
My point is that hyperscalers and other white hat hackers have been proactively running agents to find the problems to get them fixed first. It's actually pretty common that a particular vulnerability will get found by multiple teams, sometimes using different LLM's. And when they are found, they get patched quite aggresively. So while we're still finding new vulnerabilities, most of the really bad ones from code commited years earlier are getting found and once they are fixed, there is a finite supply of them. For example, RefluXFS[1] (aka CVE-2026-64600) affects all Linux kernels since 2017, so the bug was introduced almost a decade ago. And it was found in the past month, using Anthropic's Mythos LLM. [1] https://blog.qualys.com/vulnerabilities-threat-research/2026/07/22/refluxfs-a-linux-kernel-local-privilege-escalation-to-root-in-xfs-cve-2026-64600 Also, one of the reasons why Google write Project Sashiko, donated it to the Linux Foundation, and has been contributing Gemini LLM tokens for it, was to reduce the number of security bugs that were unwittingly added into new code. In an early experiment Sashiko was finding 53% of the bugs in new commits which the human reviewer had completely missed[2]. [2] https://daily.dev/posts/sashiko-an-ai-code-review-tool-for-the-linux-kernel-j5mdnowuc > The steady stream of 0-days is probably not going to stop soon, but I > hope something can be done to find missing patches for stable releases. > (Maybe now that the GR around LLM use in Debian is done, some sort of > agentic "patch hunter" can point out important patches that humans have > missed for the Debian Security Team, or something?) In the mean time, > maybe it would be worth some of my research time at work to figure out > how to make a VMM that's not quite as swiss-cheese-like as QEMU work for > convenient desktop virtualization. As far as the Kernel is concerned, the best thing Debian could do is to consider upgrading the kernel to a newer LTS. For example Debian 13 is based on 6.12. It might be a good idea to consider making 6.18 LTS at least *available*. The problem is that if a patch doesn't backport cleanly to the 6.12 kernel, the patch may get dropped. If it's a particularly infamous security issue, such as for example RefluXFS[1], people will generally make sure the relevant fixes will get correctly backported, but not all fixes will get the same level of attention. And as far as Debian oldstable and oldoldstable are concerned, <<shudder>>. There are probably many security fixes which never make it back to those older LTS kernels. I suspect that for many companies that can support their own kernel team (disclosure: I work for Google's prodkernel team), in this post- Project Mythos era they will stick to fairly new LTS kernels. So for example, once 7.4 or whatever kernel is declared to be end of year LTS kernel for 2026, best practice might be to immediately start forwrd porting any out-of-tree patches that your company might be carrying in their kernel release, start qualifying 7.4 for production, and in parallel, finish deprecating any production kernels based on 6.12 so that most of the fleet is running 6.18. That way, as soon as the 7.4 kernel has been qualified and ready for production deployment, you can start transitioning the fleet from 6.18 to 7.4. That's certainly what *I* would recommend... - Ted
