Rendered at 09:54:23 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
john_strinlai 9 hours ago [-]
note that _any_ bugfix is assigned a cve, which makes for big numbers.
>“Due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel… Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify.”
"number of cves" is a useless metric, especially when it comes to the kernel.
SAI_Peregrinus 9 hours ago [-]
Tautologically every bug can legitimately be assigned a CVE, since every bug prevents some feature from working as intended. It's therefore a denial of service, which by the definition of the CVE system using CVSS means every bug is at least a 1/Low level vulnerability to CVSS v4.0.
If you're willing to stretch, missing but planned features also deny the use of said features since they haven't been added yet, and so are CVSS 1/Low vulnerabilities.
Resume-driven development for security researchers has never been easier!
jeroenhd 3 hours ago [-]
Loads of bugs aren't CVE-worthy. If you tell the computer to make a light green but it makes the light red, that's a bug but no DoS or other CVE-worthy bug.
However, the Linux kernel is supposed to run any userland program without crashing, so anything that crashes the kernel is a local DoS and there are a lot of them. It's also supposed to shield processes from each other and maintain privilege levels correctly, so many incorrect memory leaks are also CVE worthy. Whether a CVE applies depends on the people and programs using the kernel, and the kernel team can't read your code to tell you if it applies or not.
People reading CVEs wrong ("it's got a high number so we must patch within a day") must be going crazy over this, but the point of CVEs is to let you make judgement calls, not to be a cool statistic about how secure something is.
Most CVEs are irrelevant to most people, that's always been the case.
MyMemoryfails 2 hours ago [-]
Unless that computer happens be on traffic lights. Will this become CVE? Human life would be at risk.
funcDropShadow 10 minutes ago [-]
Unless it is the led showing the status of a camera.
somat 2 hours ago [-]
"why did the ship crash?"
Unpatched bug, wrong color lights.
Yes, it is a bit of a stretch, I desperately hope programmable navigation lights are not a thing. And I also don't think every bug needs a CVE. But in the correct context nearly any bug could be critical.
seanhunter 2 hours ago [-]
Computer Weekly in the UK did some pioneering journalism into a helicopter crash[1] that had initially been blamed on the two pilots but seems very likely to have been caused by a failure of a computer system that was controlling the fuelling of the engines. Iirc this system seems to have crashed causing engine failure of both engines in heavy fog, bringing the helicopter down with a loss of everyone on board, however for reasons somewhat unclear, the MOD wanted to cover the failure up by blaming the pilots.
Now this was a windows system[2] rather than linux but the point remains - if there was an external vulnerability in a crucial control system and this system was part of a network (eg to connect telemetry) then any exploit of that system could result in loss of life.
After an assessment of the Fadec software the Superintendent of Engineering Systems said that the density of deficiencies was so high that the software was unintelligible.
[2] Which, why? Why build the fuel controller for a helicopter engine on windows?
rjsw 43 minutes ago [-]
Are you sure that the Chinook used Windows? I have not read this elsewhere.
There have been documented problems with Windows for Warships.
viraptor 8 hours ago [-]
> It's therefore a denial of service
That doesn't follow. In the extremely simple example, an adding service returning 1+1=3 has a bug, but it's not a possible DoS situation at all.
> missing but planned features also deny the use of said features
That's not what DoS is.
This whole situation with CVE assigning comes from the whole process being far from ideal. But it doesn't mean it's completely useless and doesn't follow any rules at all.
Gigachad 8 hours ago [-]
>but it's not a possible DoS situation at all.
Until someone finds there is a user input they can trigger this bug causing some other bit of code to read data from the wrong offset and now it's a whole exploit.
viraptor 7 hours ago [-]
That's an issue in the other code, not in the addition service. It would be lumped together if it was an addition function close to the other code. But I wrote service there on purpose.
someonebaggy 6 hours ago [-]
Why couldn't a crash caused by filesystem corruption caused by a + operator that says 1+1=3 be filed as a DoS?
tsimionescu 3 hours ago [-]
It could. But it's a CVE in the system that crashed or in the filesystem, not in the calculator web service that we were discussing. If a filesystem decides to use a bad online calculator for its internal logic, that's a vulnerability on the filesystem, not the calculator.
asdfaoeu 1 hours ago [-]
We aren't talking about a calculator web service though we are talking about the Linux kernel and if there's a bug in the kernel that could conceivably cause a crash in an otherwise correctly written application then that would be a CVE in the kernel.
4 hours ago [-]
asdfaoeu 7 hours ago [-]
It's not hard to imagine an application for which 1+1 = 3 leads to security issue.
That’s not what Mitre thinks though, they are very happy to host a 9.8 severity CVE for 1+1=3. They’ll probably publish one for 1-1=0 too, if you preface with ”The users of mathematics might not be prepared for zero values”
viraptor 2 hours ago [-]
You're memeing on bad cve handling, but that's so far outside of what the real issues are, it just doesn't make sense. How about telling people about what the real problems with vulnerability classification are, rather than mitre=bad?
nikanj 1 hours ago [-]
The real problem with vulnerability classification is that mitre=bad
This is why you need a library for additions. At least CVEs can be tracked appropriately, rather than the developer rolling out their NIH solution.
josephg 4 hours ago [-]
There’s probably an npm library for that. Not all heroes wear capes.
spragl 3 hours ago [-]
[dead]
st_goliath 2 hours ago [-]
> _any_ bugfix is assigned a cve
Any patch that is back ported to a stable kernel, indiscriminately. And they have also started assigning CVSS scores with the same kind of malicious compliance.
Take for example, this patch in the device mapper RAID code:
Reasoning behind it being that theoretically, a RAID could be accessible over the network via NFS, iSCSI, etc... so if it gets corrupted, the buggy code path in the recovery (CVE-2026-89558) is effectively triggered over the network.
mbreese 8 hours ago [-]
> note that _any_ bugfix is assigned a cve
I do find it interesting though, that in the interest of transparency, every bugfix gets a CVE. Which ends up being a huge number… which will ultimately yield a more insecure environment as we’re getting conditioned to ignore/discount CVEs by the volume.
Over-reporting in this case seems to risk being counterproductive.
socializer 7 hours ago [-]
It's not very interesting. Linus, and by extension the Linux kernel, long had a dismissive attitude toward security research. This is basically a childish swing from one extreme (nothing gets a CVE) to another (everything gets a CVE).
Kernel development is well-funded, both via grants and by direct employment at big tech companies, and if they wanted to properly triage and annotate vulnerabilities, and provide reasonable assessments of what is or isn't likely to be a security risk, they absolutely could. They almost certainly could go to Google and say "we need two people full-time on your payroll for this" and they would get it.
I don't want to dunk on them too much because they're generally doing God's work, but these absolutist security stances are not worth being taken seriously.
It's basically saying that they can't possibly provide a valuable service for 99.999% of the install base because there might a hypothetical person out there using Linux in a really weird way. If Microsoft tried to make an argument like that, they'd get crucified.
serbuvlad 3 hours ago [-]
I don't think that Linus is dismissive of security, it is that he is very much a proponent of always rolling to the latest stable release.
Linux only ever wanted to promise support for the latest release and even Linux LTS is a concession.
And CVEs are basically a useless concept if you roll. (or at least not any more useful than any other bug tracker which supports tags)
LtWorf 2 hours ago [-]
> Linux only ever wanted to promise support for the latest release and even Linux LTS is a concession.
If he kept true of his "we don't break user space" instead of it being "we don't break user space until we do and then it's on you to deal with it" perhaps more people would be willing to run the latest release.
asdfaoeu 7 hours ago [-]
Let's say they do and only 5% are "security issues" you still need to update either way.
vlovich123 7 hours ago [-]
The counterpoint is that by putting CVEs on bugs that are more easily exploitable provides a roadmap for attackers. Of course, in the current LLM age that's probably a moot point, but that could be the reason for this.
weinzierl 3 hours ago [-]
Counterproductive for whom? The stance of the kernel developers is that whether a bug is a vulnerability or not depends on intended use. They say, we do not dictate use, therefore this decision is out of scope for us. This makes kernel development more focussed and productive.
I would argue that it is more productive for the enduser as well. Not making a decision they cannot reasonably make is better then blindly believing in a decision that is likely wrong for your usecase.
Gigachad 7 hours ago [-]
Depends on the end consumers stance on security. I've watched it shift from "Only update if we can prove we are impacted" to "Update everything immediately just in case".
The frequency and severity of cyber attacks has increased to the point a much more cautious approach has become common. It's also easier to sell this work to management when you can point at the security tab on some tool and say "Look we need to patch these CVEs"
autoexec 5 hours ago [-]
"Update everything immediately just in case" is a lot less attractive when you see more downtime from updates breaking things than you do from hackers. Windows updates are an endless source of pain, but now every program seems to demand to be updated practically daily. Even things that you shouldn't have to think about like keyboards, mice, and printers beg to be updated all the time.
Gigachad 3 hours ago [-]
Downtime is annoying but workable. You can't unleak customer data after your system gets hacked.
1718627440 3 hours ago [-]
There is no reason, why a newer version has less bugs, than an older version. Both are essentially an unknown number. The only thing you know, is that you likely know a higher percentage of bugs for the older than for the newer version.
Gigachad 2 hours ago [-]
It certainly has less known bugs. And when you have to make a statement to the media, “we were hacked by an undiscovered 0 day exploit” sounds a lot better than “we were hacked by a known exploit because we didn’t update”
1718627440 2 hours ago [-]
If you do know about it, you can also just mitigate that.
someonebaggy 6 hours ago [-]
They chose to do it this way, in. part, because CVEs were already like that, and too many people were pretending they weren't.
rerdavies 9 hours ago [-]
With particular emphasis on "almost any bug might be exploitable".
SoftTalker 8 hours ago [-]
Even a bug-free program might be exploitable.
catlifeonmars 8 hours ago [-]
That sounds like a bug
SoftTalker 8 hours ago [-]
There are programs like sudo whose entire reason for existing is to enable privilege escalation. If you can find a way to make a user "sudo" something, that's an exploit, but it's not a bug in the program.
odo1242 8 hours ago [-]
At that point you're exploiting the user, who is not a bug-free program
rerdavies 5 hours ago [-]
Remove user and press any key to continue.
:-P
PaulDavisThe1st 5 hours ago [-]
Alternatively, consider any program which loads dynamic shared libraries (called "plugins" in many contexts). The program itself might be bug free; any plugin that is loaded will run (typically) with the full priviledges and access of the program (and thus likely the user).
The user may have no idea that the plugin is malicious; the program remains bug-free (if it was beforehand).
catlifeonmars 7 hours ago [-]
But if you squint, it might be a bug in the system to allow access to that program.
bigstrat2003 6 hours ago [-]
That's also not exploiting the program, it's exploiting the user.
PowerElectronix 2 hours ago [-]
Totally a feature
8 hours ago [-]
chrisjj 1 hours ago [-]
> Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify.
Er what?? CVEs should be assigned to bugs, not bugfixes, right?
aiXis 2 hours ago [-]
[flagged]
intrepidsoldier 6 hours ago [-]
Just the beginning. AI is going to expose how fragile the entire computing infrastructure in our world is.
flohofwoe 12 minutes ago [-]
No, it will be a tsunami of new discoveries in old code bases at first, but that will settle down as those old bugs are fixed. It's been like this with every new code analysis tool (the wave may be exceptionally high this time though).
chii 5 minutes ago [-]
> AI is going to expose how fragile the entire computing infrastructure in our world is.
this is a good outcome. A forcing function to encourage all computing to be more secure can only be good in the long term, even if there's a lot of pain in the short term.
ankurdhama 6 hours ago [-]
Does this also mean the code generated and reviewed by LLMs will not have such issues going forward?
flohofwoe 7 minutes ago [-]
It depends? LLMs are not a silver bullet for writing bug free software (IME at least, and of course it also depends on the "threshold" what actually counts as a bug).
They're definitely a useful additional tool for finding more (and more obscure) bugs, but that takes a lot of both human and compute effort too, and after the reports are clean you still can't be sure if all bugs were found.
Gareth321 2 hours ago [-]
You're going to get a wide range of responses on this but given the improvement in these models in just one year, and the number of bugs they're detecting which humans could not, I suspect that even median vibe-coded software is going to surpass median human coded software soon - if it hasn't already.
The important thing to remember here is there perfect isn't on the table. The benchmark is existing human-introduced bugs vs LLM-introduced bugs. Many developers have encountered odd bugs which a human would not have introduced, while forgetting about all the bugs caught which humans introduced. Or their opinion is formed by models from six months ago.
lrvick 12 minutes ago [-]
Depends on if people are willing to pay the extra wall time to write mathematical proofs for everything to make it provably correct. Takes way way longer but modern models can do it.
trollbridge 6 hours ago [-]
Quite the opposite, particularly when the biggest vendors of coding agents insist on not allowing their models to be used to check the code they generate for security issues.
miohtama 5 hours ago [-]
Why stop there? We should regulate who is allowed to write code in the first place!
bsoqk 51 minutes ago [-]
So, like professional orders in Europe? Thankfully everybody agreed that writing code is not engineering so this isn't mandated by law, but we were this close.
autoexec 5 hours ago [-]
Easily done if everyone can be convinced that learning to write code is pointless since you can just pay an AI company for access to a chatbot that will write it for you.
Fortunately there are people who write software for fun so there will always be some people who would rather do it themselves.
jumploops 45 minutes ago [-]
“And that was how CS became a real engineering degree”
enraged_camel 5 hours ago [-]
I've been able to use Opus 5.5 and Fable 5.1 for defensive security audits without any issues. They cannot do offensive tasks like pen-testing but in a lot of cases that's not a big shortcoming.
hgoel 5 hours ago [-]
If the Western AI companies get their way, only the developers/companies that have access and paid extra for the security review will get to have a lower chance of such issues.
bottlepalm 6 hours ago [-]
It won't which means inevitably malicious AI will probably backdoor us. Damned if we do, damned if we don't.
mapontosevenths 5 hours ago [-]
I'm an arms race the only winner is the arms-dealer.
Brian_K_White 6 hours ago [-]
It just means that there will be the equivalent of infinite man-hours of barely-functional-intelligent-man to slog through code word by word and track how it affects all other code relation by relation.
It's not magic and it's not even better or even as good as a mid human, but it's something like infinite man-hours of that drudge work per hour per user.
That will find a lot in old code, and make it a lot easier to keep on finding every little thing right as it's created in new code.
larodi 18 minutes ago [-]
While I totally agree with the statement, question is - is this challenge even solvable? Though where I come from there is a proverb - "for every malady there's a remedy", wonder what it can be this time.
And, of course, there are piles of legacy corporate spaghetti entangled in incomprehensible mess everywhere you look at. And this shit still runs, this precious hand-carved hand-weaved mess of bad decisions. I can't wait for LLMs to rewrite most of it.
Iolaum 12 minutes ago [-]
As long as people use AI to review new stuff before they ship the ratio of vulnerabilities waiting should be trending downwards. Still, likely to be a bumpy ride.
PowerElectronix 2 hours ago [-]
Good thing we can patch those issues up and have an ironclad system afterwards.
jaypatelani 5 hours ago [-]
Because most devs don't want to do formal verified system development. I know only one OS working on that which is open source Ironclad OS hope many others follow this path. It is Ada/SPARK based but others should do with whatever language they are using. NetBSD also heard going to do something similar with C in last AGM
menaerus 2 hours ago [-]
Do you make your professional career by building formally verified systems? I ask because I don't think that the reason comes down to "because most devs don't want to do formal verified system development". It's much more complicated of course.
stackskipton 17 minutes ago [-]
I could believe it. Verified system development most likely comes with metric ton of paperwork.
Want to merge the PR? I need verified sign off in ServiceNow by staff level engineer. They are on vacation for 2 weeks? Did manager fill out delegation paperwork in ServiceNow with VP sign off? Oh they did but they forgot to put in return date AND time. Form needs to be corrected and reapproved before we can go into ServiceNow and make changes.
RossBencina 4 hours ago [-]
> most devs don't want to do formal verified system development.
That may be true. Serious question though: even if most devs wanted to develop formally verified code, do you think that it is reasonable to suggest that the typical systems developer could do it with today's tools? I don't mean verified protocols (TLA+) or verified algorithms (SPIN) I mean end-to-end verified code, a-la seL4. I got the impression that this is still very specialised work. Perhaps things have advanced since I last checked.
I am an experienced engineer and am building a product actively right now. I started pre-AI, and cautiously adopted AI. I am using AI tools a lot now, but still dedicate a lot of my attention to validating it's output and design decisions.
I recently asked it to review my code and configs from the security perspective. Wow! 90% of the things it identified were MY bad decisions dating from pre-AI development. I am honestly humbled and impressed at the same time.
AI can create slop, and it can create quality products. It depends who is using it, and how.
worldsavior 4 hours ago [-]
Who said those vulnerabilities were found by an LLM?
ricksunny 1 hours ago [-]
And the aspie award goes to…
senectus1 5 hours ago [-]
in theory, it could be the best thing that ever happened to open source.
I'm not super sure about that. But if its going to exist I'm crossing my fingers it works to the OSS community benefits (eventually)
ex-aws-dude 4 hours ago [-]
wouldn’t it result in whoever has the most money having the most secure software?
AnonymousPlanet 3 hours ago [-]
Eventually whoever has the most energy.
mihaaly 2 hours ago [-]
Broadcast, not expose.
We knew that for long time, there are countless meme about it, smart people protected their asses from it or exploited those.
lolakutty 4 hours ago [-]
> fragile the entire computing infrastructure in our world is.
It was "load bearing" just fine....
Anything is "fragile" if you put a bulldozer over it....
nicman23 4 hours ago [-]
i mean if the building needs to be bulldozer proof..
1718627440 3 hours ago [-]
But it doesn't need to if you lock up the bulldozer maniacs.
BLKNSLVR 1 hours ago [-]
Which won't happen when the bulldozer machines are the proxy for the cold-war with China.
EGreg 5 hours ago [-]
Instead of patching millions of environments, perhaps it’s better to just build a secure one from scratch?
I thought the "Security in the LLM age" talk by Greg Kroah-Hartman published this week from Kernel Recipes was pretty interesting: https://www.youtube.com/watch?v=NnV_cWeoo5Q
sashank_1509 54 minutes ago [-]
Yeah it’s a great video (TLDR from the video)
1. LLMs have high false positive rate. From mythos 79 vulnerabilities found in the Linux kernel, only a single digit were actual bugs and they were all obscure so don’t panic.
2. What does obscure mean? I don’t really understand it, but many of the bugs have to do with custom network drivers or other custom drivers that are very specific to certain organizational setups, not a general Linux distro issue.
3. He’s very frustrated with the high false positive rate mythos generates. Even after multiple rounds of adversarial review and prompting strats, he mentions it is > 20% false positive rate, which wastes a lot of time. When some random user on the internet brings up a bug with an LLM it’s almost always fake, he even says just push back a few times claiming it’s not a bug to see if it’s a real bug (LLMs very quickly cave and “notice their mistake” etc)
4. General observation on the useful bugs mythos finds. Chain multiple smaller bugs to see if you can get a bigger breakage. Mythos is really good at constructing these long convoluted chains that fuzzers miss.
5. Go through recent bug fixes and check if similar bugs are hidden elsewhere in the codebase. Mythos is good at such pattern matching albeit with a high false positive rate.
Final conclusion: don’t panic, the bugs are getting fixed, this is not as bad as the first fuzzer bug mania and will be fixed quicker, he estimates a year and we won’t see huge bug reports anymore.
BLKNSLVR 54 minutes ago [-]
500 CVEs per release to 2000+
Extending the ratio from my other comment. What are the token ratios between using LLMs to:
1. Create functional software
2. Find bugs in functional software
3. Triage/Prioritise a quadrupling of the reported CVEs
4. Fix the bugs while keeping the software functional
I'm assuming that #2, #3, and #4 require more tokens (each or cumulatively) that #1, then there will be increase in the amount of insecure software because, with the advent of LLMs (that allow otherwise non-software developers to become software developers), there will be (a lot?) more software being created.
If we want software security to get better, then the existence of LLMs requires the increasing use of LLMs. I find this quite interesting.
omarali-me 39 minutes ago [-]
Excellent plug and recommendation!
BLKNSLVR 1 hours ago [-]
What is the token ratio of 'AI writing software that works' to 'AI finding vulnerabilities in software that otherwise works'?
Even with AI there's an asymmetry separating 'functional' from 'secure'.
As with software development prior to AI, security has a cost associated with it, and unless there are _real_ consequences, it's a cost that most software houses ain't gon' pay.
HolyLampshade 25 minutes ago [-]
> security has a cost associated with it, and unless there are _real_ consequences, it's a cost that most software houses ain't gon' pay.
Good to see someone say this. Software need only be good enough to do the job, and only as safe as reasonably required. Systems can be secured and audited through other means, sometimes at lower expense than guaranteeing every line of software has zero risk associated.
romaniitedomum 6 hours ago [-]
An interesting observation that I encountered somewhere, I forget where, is that AIs when writing code introduce vulnerabilities at a rate similar to humans writing the same code. So we're looking at a massively accelerated volume of security vulnerabilities for the foreseeable future thanks to AI-assisted security research, and we can expect no reduction in new vulnerabilities from the AIs writing the code.
biwills 5 hours ago [-]
Do we know the code behind these vulnerabilities were written by AI? It seems like if anything AI was used to find exisitng vulnerabilities that would otherwise be used/sold as zero days and go unreported.
It was always the case that finding vulnerabilities in software was easier than writting perfect software. I'm hopeful that we can use AI to make software more secure over time. Project Zero [1] and others has shown many times the past few years (pre LLMs) that automated fuzzing and other forms of dynamic analysis are very effective, which bodes well for automated testing via LLMs!
I agree that more code = more bugs overeall, but there are slow moving codebases that run some of the worlds most valuable software. Seems like using AI to find vulnerabilities in that code is a huge win across the board.
> Do we know the code behind these vulnerabilities were written by AI? It seems like if anything AI was used to find exisitng vulnerabilities that would otherwise be used/sold as zero days and go unreported.
I was speaking in the general sense, not of these vulnerabilities specifically. I am of the view that AIs for the foreseeable won't produce code that is any better from a security point of view than something human written, so AIs will produce new vulnerabilities at least as fast as they find them and the rest of us will be faced with massive headaches like the one in the original post.
> It was always the case that finding vulnerabilities in software was easier than writting perfect software. I'm hopeful that we can use AI to make software more secure over time. Project Zero [1] and others has shown many times the past few years (pre LLMs) that automated fuzzing and other forms of dynamic analysis are very effective, which bodes well for automated testing via LLMs!
And yet, we are not seeing a drop-off in new vulnerabilities being discovered. We keep assuming that the list of bugs is getting smaller and we'll find them all eventually, but that is not the case for any software that I know of.
> I agree that more code = more bugs overeall, but there are slow moving codebases that run some of the worlds most valuable software. Seems like using AI to find vulnerabilities in that code is a huge win across the board.
It might be, yet, as I said just above, we are not seeing a drop-off in new vulnerabilities being found. The trickle of vulnerabilities has become a flood across all open source software, and already breakages and problems are occurring as maintainers struggle to keep up. Administrators, likewise, are struggling to keep systems updated. Just a week or so ago a security patch to rsync on RHEL broke rsync so completely that it could no longer handle symbolic links.
Critical CVEs used to be relatively infrequent, but they're becoming a weekly or even daily occurrence. None of us are prepared for this eventuality.
zahlman 14 minutes ago [-]
> I am of the view that AIs for the foreseeable [future] won't produce code that is any better from a security point of view than something human written, so AIs will produce new vulnerabilities at least as fast as they find them and the rest of us will be faced with massive headaches like the one in the original post.
If you simply prompt them to produce code, with the same kind of processes that humans use, then yes, of course. After all, it trained on human code.
If you prompt them explicitly to spend time looking for vulnerabilities and not implementing new features, then why wouldn't it produce more secure code? If we're calling the technology a "force multiplier", then it's thus for every task it can perform. So, orient the process around that; avoid the compromises that were originally motivated by working at human speed (, interest level, fatigue, specialization, …)
Of course, if you see places where the application of artificial "intelligence" can benefit from human wisdom, then double down on that. (Quotes because I think the term is fundamentally inaccurate for what it refers to, even though it's typically good enough and refers to a useful capability.)
autoexec 5 hours ago [-]
> AIs when writing code introduce vulnerabilities at a rate similar to humans writing the same code.
AI regurgitating all the insecure code AI companies scraped from stack overflow and github isn't going to give you something too different from what the humans who put it there in the first place came up with. Garbage in, garbage with random hallucinations out.
red75prime 4 hours ago [-]
This is simplistic to the point of being blatantly wrong. Training data isn't garbage. It's programs that do their job, but that are sprinkled with errors. Uncorrelated errors gets averaged out during autoregressive pretraining. Correlated errors can be somewhat suppressed during post-training. Hallucinations (of the generalization-error kind) can be dealt with using synthetic data that improves the model's generalization.
deadbunny 37 minutes ago [-]
So with all those mitigations why do LLMs keep writing insecure code?
red75prime 29 minutes ago [-]
Provable correctness is much harder than focusing on the happy path. If a pipeline doesn't include a look-for-the-vulnerabilities stage to save costs, a model wouldn't go out of its way to do it. The models are trained to do what they are asked to do.
I forget to add the obvious: some garbage gets through despite the mitigations. In the limit of pure garbage input, you'll get a model that internalized garbage generation. And you'd be better off throwing it away and starting over.
PowerElectronix 2 hours ago [-]
I guess trash in trash out also applies to the training of an LLM.
baq 5 hours ago [-]
It doesn’t follow. Everyone sane has the models review the choose the models wrote. Reminder these are the models which found the Jacobian and Navier-Stokes counterexamples; they’ll find holes in their own slop, too.
layer8 3 hours ago [-]
These counterexamples are comparatively straightforward because the input domain is well-defined and simply-structured, and a counterexample is trivial to verify. The same is not true for arbitrary vulnerabilities.
baq 3 hours ago [-]
Computers are finite. Inputs are well defined and so is their structure (ignore for a second the fact that it’s all physics behind the scenes). Secure code is a conjecture. A counterexample for secure code processing bits is an exploit.
Also I find calling millennium problem solutions ‘straightforward’ baffling, to be polite.
NoPicklez 5 hours ago [-]
Yes and no, many people don't have models review the code the same way many humans don't review their own code in depth for security vulnerabilities.
Furthermore, you need to make sure the model you use is capable enough to review your code comprehensively enough. That includes for both basic vulnerabilities but also attack chain related vulnerabilities.
mepiethree 5 hours ago [-]
Then a new model comes out two weeks later and finds a hole that your archaic review bot missed
baq 2 hours ago [-]
Fortunately, for now. Imagine the models not being released publicly.
romaniitedomum 1 hours ago [-]
> Everyone sane has the models review the choose the models wrote. Reminder these are the models which found the Jacobian and Navier-Stokes counterexamples; they’ll find holes in their own slop, too.
It's not enough, though, to just tell the model to check the code for vulnerabilities. The model has to be guided specifically to look for particular classes of problem and that takes someone experienced in security.
Fordec 9 hours ago [-]
This is great, more access did provide more eyes on these problems.
But, does that all of these being found now call into question, not the open source model logic itself, but the ability of human eyes to find security issues? These vulnerabilities have been sitting here for however long, but how many thousands of humans did not find them before AI?
spoaceman7777 8 hours ago [-]
The threshold for Microsoft and Apple to actually report vulnerabilities is MUCH MUCH higher than for Linux, and open source as a whole. They generally only disclose issues in Windows and macOS that are quite serious and impactful.
For Linux, the threshold is nearer to the point of it being questionable whether a bug is even exploitable on a real production distro, compiled and run with any sort of sane configuration.
hn_submit 1 hours ago [-]
Microsoft only fixes vulnerabilities which are actually being abused or remotely exploitable. Otherwise they'd never get any work done.
SchemaLoad 9 hours ago [-]
Even before AI we have known that no one is smart enough to write bug free C. And with every bug being a launch platform for a full exploit it's become a big deal.
1over137 8 hours ago [-]
No one is smart enough to write bug free in any language.
zakisaad 8 hours ago [-]
This is the reason why performant and "safe" systems languages are on the rise and being accepted into foundational areas of our operating systems (such as the kernel). When the attack defense surface is tighter (language, tooling, compiler instead of the actual code itself), the smart folks can stay at that layer, while the masses can write more code at a level of abstraction that nullifies many of these vulnerabilities by default.
I can't find it now, but I heard that NASA developed processes to produce completely error-free code (for the moon landings iirc). The problem is that it's incredibly time consuming and expensive to do.
Like everything in CS, apparently this is a trade-off, not an absolute. You can get bug-free code, but it's not commercially viable and is extremely tedious to do.
kccqzy 6 hours ago [-]
It’s probably about how they write the space shuttle software, and it’s quite a famous article. The original is now paywalled but there are many copies.
This is example of what I call "the tipping paradox", and I'm almost sure that this phenomenon has its own proper scientific name.
When asked, people prefer €15 burger no tip, but when actually making a choice, they prefer €10 burger with €5 tip. Similarly, companies state "bug-free code" as a goal or requirement, but then they prioritize other goals over code correctness. My workplace is in the process of completely removing code reviews. And actually, I don't disagree with the decision - my career is short, but I have never seen reviews fulfill any purpose other than to share the blame in case of an incident.
cindyllm 3 hours ago [-]
[dead]
SchemaLoad 8 hours ago [-]
That's why we designed better languages that can block the compilation if memory hasn't been handled properly.
wat10000 8 hours ago [-]
The difference is that C casually makes common everyday bugs into security vulnerabilities.
0c3ca83 8 hours ago [-]
AI makes language choice a lot less important here; it's incredibly good at finding the bugs.
It's incredibly problematic for many reasons, but it finds bugs in C really well.
NoPicklez 5 hours ago [-]
Some vulnerabilities are incredibly complex and are identified not through the code itself but through various attack chains being strung together.
Also there are likely a lot of vulnerabilities identified but the work required to fix them vs the complexity to exploit them means they don't get fixed.
I'd wager we don't have an issue with identifying vulnerabilities but the ability to fix them.
I work in security consulting and identifying vulnerabilities isn't the difficult part its actually fixing them and fixing the ones that have valid exploitable attack chains that matter
tetrisgm 9 hours ago [-]
That’s probably a great thing. The initial friction of AI overwhelming projects certainly sucks, but once there are better processes to deal with them it’s going to strengthen the quality of so many projects!
SchemaLoad 9 hours ago [-]
Long term we will end up with software with no low hanging fruit exploits left. But right now we are in a period where low hanging fruit is everywhere and it's easier to exploit systems than ever before.
somenameforme 8 hours ago [-]
That relies on a major assumption that current systems are finding the vast majority of all possible exploits out there. This assumption itself would assume that either current LLMs are near perfect, or that the peak difficulty for exploits was just above human capability (which is where LLMs currently are). I think both of those assumptions are very likely false. If so then we'll see indefinitely ongoing exploit discovery as LLMs improve their capabilities.
Long term I suspect that the purpose of the digital domain is going to end up being rethought. For instance connecting critical infrastructure to the internet has always been a terrible idea, and LLMs will just make that even more clear.
SchemaLoad 7 hours ago [-]
Computers are becoming architecturally more secure alongside just patching bugs. We have seen the move to using VMs with a minimal hypervisor, using separate security chips to hold sensitive info like encryption keys, Memory Tagging to detect and prevent memory exploits.
On the iphone for example even if you find a crippling bug in iOS which gives you full root access, there is still no way to get the device encryption key or face ID info because the secure enclave simply has no electrical connection that can pass that key to the OS.
catlifeonmars 8 hours ago [-]
That’s assuming we’re not adding software defects at the same pace, but I imagine we are generating a lot more defects than are being discovered at the moment.
skeledrew 7 hours ago [-]
> we are generating a lot more defects than are being discovered
Wouldn't this mean people are actually encountering issues where there are none before? Likely some serious enough that they lead to exploits where there weren't before? Where are the reports of these new defects?
catlifeonmars 7 hours ago [-]
I just mean there is a proliferation of new code. New code == new defects. It’s likely that popular software projects get the majority of the scrutiny, while no one is spending tokens looking for defects on my 0-star GitHub repo.
kamma4434 4 hours ago [-]
I fear the vast majority of projects never went with any kind of code review but somebody high on Red Bulls at 9 PM looking at the code and saying “looks good to me”.
And this is the best of cases. I fear many times in a smaller projects it was “it compiles at last, let’s see if anybody complains”. That’s why LLM’s are so damn effective today.
(been there, done that – I’m not pointing fingers, but we are human, we get tired, and we don’t have the NASA budget to complete things and ship them)
userbinator 9 hours ago [-]
Several vulnerabilities have been discovered in the Linux kernel that may lead to a privilege escalation, denial of service or information leaks.
Remotely or locally exploitable? This is very lacking on information.
SchemaLoad 9 hours ago [-]
If they were bugs of consequence you could expect each one to get it's own domain with a scary name and a logo.
adastra22 9 hours ago [-]
Unfortunately no, there are a lot more that fly under the radar.
walrus01 8 hours ago [-]
If any of these were remotely exploitable it would be getting much louder and more urgent news. Local privilege escalation bugs are encountered all the time.
fractal618 6 hours ago [-]
I wish everyone used the same versioning system for all software: A.B.C increment C for security patches, increment B for new features, increment A for systemic changes.
orf 48 seconds ago [-]
[delayed]
drewfax 6 hours ago [-]
Linux kernel introduces bug fixes, new features, and major systemic changes all the time. That’s why using SemVer for Linux is pointless and why Linus dropped it.
atoav 6 hours ago [-]
Well, this is called semantic versioning (semver) and it is the most popular versioning system out there: https://semver.org/
However I see software variants where simple numbers work as well, e.g. Firmware code that runs on totally self contained hardware is often just versioned with simple integers, that is because most updates (releases) of that software contain both features and bugfixws and "breaking changes" don't apply to stuff that doesn't read or write files. So you could use semver and have 1.50.0, 1.51.0, 1.52.0 forever, but by that point you can just give it aimple integer versions.
dash-44 6 hours ago [-]
I believe they call it semantic versioning (SemVer).
modeless 11 hours ago [-]
1,313 vulnerabilities, to be precise.
nathell 9 hours ago [-]
In Heroes of Might & Magic 3, “several” means 5–9. 10–19 is “pack”, 20–49 is “lots”, 50–99 is “horde”, 100–249 is “throng”, 250–499 is “swarm”, 500–999 is “zounds…” and 1000+ is “legion”.
I suggest this post be renamed “A legion of vulnerabilities has been discovered…”
rotis 2 hours ago [-]
Maybe we should use legion as a collective noun for vulnerabilities. Like murder of crows or school of fish. Would signal the urgency no matter the actual number or impact...
thallium205 10 hours ago [-]
Pretty much any kernel bug gets a CVE by default now, right?
wjholden 10 hours ago [-]
Is that all there is here? The quantifier "several" did not prepare me for the wall of CVE numbers in this list.
vdfs 9 hours ago [-]
https://docs.kernel.org/process/cve.html states that because almost any kernel bug can potentially compromise system security, the CVE team acts with extreme caution and labels nearly all bug fixes with a CVE
slopinthebag 9 hours ago [-]
yes because the majority are memory safety issues, and it's automatically assumed that a memory safety bug can lead to a vuln
one again illustrating the importance of encapsulating unsafe behavior. perhaps c should get a __UNSAFE { } block, where memory access is encapsulated and thus most bugs occurring outside of those blocks do not need to be marked as CVEs.
akersten 9 hours ago [-]
> perhaps c should get a __UNSAFE { } block,
I think the convention for this is at the filesystem level and most programmers use the `.c` suffix to indicate it
branc116 1 hours ago [-]
cheap shot lol
slopinthebag 9 hours ago [-]
in that case we need a block of system memory marked as unsafe so i can run these programs in it encapsulated
perhaps we could call it a sedimentchest?
catlifeonmars 8 hours ago [-]
I think that’s just called “memory”. Encapsulation is your machine.
someonebaggy 6 hours ago [-]
See xkcd's sandboxing cycle. They exist, they're called processes
debugnik 3 hours ago [-]
C has many more ways to trigger undefined behaviour than memory access. If C had unsafe blocks they'd restrict most forms of signed integer arithmetic and shifting, for a start.
insanitybit 5 hours ago [-]
No. It's because Greg doesn't like the CVE system and MITRE, the stupidest decision ever, made Greg a CNA, and this is his tantrum that he's been waiting 40 years to throw.
seba_dos1 9 hours ago [-]
Yes. It looks funny, but it's a nothing burger.
sva_ 9 hours ago [-]
Seems like the CVE sequence has, for the first time, reached >100000 this year (Which does not imply 100k vulns though)
Apparently by late summer this year, there were already more vulnerabilities found than in all of 2025.
cryptonym 2 hours ago [-]
By late summer this year more software/code was produced than in all of 2025
BobbyTables2 9 hours ago [-]
Are these primarily AI-assisted findings ?
Seems like an enormous increase over 2024 and 2025.
ganelonhb 9 hours ago [-]
Yes, naturally. It’s a brave new world.
9 hours ago [-]
hn_submit 5 hours ago [-]
We need to switchover to microkernel operating systems ASAP or our entire computing infrastructure becomes a liability.
There are good reasons for QNX becoming viable again in the automotive world. Linux / Android has so many vulnerabilities that it needs indefinite patching, which is unrealistic for any computing device but cars especially. Car makers are switching to QNX even though it costs them money.
Weren't there rumours that intelligence agencies have been using microkernel operating systems for decades?
TacticalCoder 42 minutes ago [-]
> Car makers are switching to QNX even though it costs them money.
My car runs QNX for its infotainment/navi system but I had the impression that manufacturers were, sadly, moving away from QNX?
FlowingRiver 2 hours ago [-]
GNU Hurd shall rise!
tpoacher 2 hours ago [-]
Along with its Hirds!
fsflover 1 hours ago [-]
Alternatively, we could benefit from security through compartmentalization. Qubes OS runs everything in VMs, and there were two VM escapes in the last 20 years [0]. A dedicated VM for your email doesn't allow any attacker to compromise it, since you do not run anything else in it.
You cannot possibly compare embedded/single-purpose systems to a general-purpose OS that is expected to run arbitrary user-written software performantly on thousands of different hardware combinations.
hn_submit 2 hours ago [-]
Then don't use a general purpose OS in embedded stuff. Yet everyone's doing it anyway.
P.S.: QNX is a general purpose OS as well and runs on PCs, ARM and a myriad of other architectures. Same holds for MINIX and Sel4.
snvzz 3 hours ago [-]
>Weren't there rumours that intelligence agencies have been using microkernel operating systems for decades?
Governments, military, aviation, space.
For a good portion of the usage, the people involved cannot even talk about it. But sometimes it's possible. A surprising amount of real world use showed up in talks in seL4 summit 2026[0].
I remember this guy selling an operating system to intelligence agencies. I believe it was essentially MINIX or Sel4 with a GUI layer on top.
The government isn't telling anyone about it because they don't want to sink a multi-trillion dollar corporation.
DominoTree 10 hours ago [-]
I was looking earlier and the majority of these do not have a CVSS score assigned to them yet, but a lot of them that did were >7.0 (although I suppose by nature that the more impactful CVEs are going to be scored more quickly)
drfloyd51 9 hours ago [-]
Is it possible that some of these bugs were already exploited by governments? And AI might help use close of that kind of thing? (And expose other kinds of things , in a kind of AI arms race?)
bhouston 9 hours ago [-]
Probably. Organizations specializing in hacking are probably having a great time hacking everything and installing permanent presence. It is probably like a gold rush period.
sippingabonedry 9 hours ago [-]
Will everyone chill the F out for a minute?
These get released every few weeks. Tons of CVEs. If a kernel developer farts in the forest, does anyone hear it?
August saw separate Debian kernel updates released four days apart. Does anyone even reboot that often?
I have three kernels installed over the last 45 days or so and I probably missed a few.
nightfly 8 hours ago [-]
I've been doing Linux sys-admin work for 10+ years. Used to be I could read the full report on what ever vulnerabilities came out and triage which servers needed to be updated now and which could wait. A few years ago notifications started having so many it would take more time/effort to read everything than it would to patch everything. With this notification there's even ten times more...
Gigachad 7 hours ago [-]
That's because the methodology changed in 2024
>Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team are overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team.
The amount of updates on Debian "stable" has become ridiculous, it's a daily rolling release of backports at this point.
Microsoft kinda got this right by doing it once a month, unless it's something horribly bad, you can plan your maintenance around a predictable calendar.
vortext 8 hours ago [-]
You can choose to only install updates that require a restart once a month on Debian, then it's the same.
tclancy 8 hours ago [-]
Regarding the fart question, it depends on the audio driver and the underlying codec. While you would think “free as in beer” would make for truly resonant flatulence, only truly letting loose (plus a Bic lighter) brings real enlightenment.
SoftTalker 8 hours ago [-]
We're considering weekly reboots at work now with the pace of kernel updates coming out, and the speed with which vulnerabilities are getting exploited.
sippingabonedry 8 hours ago [-]
There is exactly one CVE in the entire list that is high severity, and it affects an obscure IBM NIC driver for big iron systems used in companies with more money than brains.
You can skip the Xanax this week.
Gigachad 7 hours ago [-]
Problem is it takes more effort to read the CVE list and work out if you have one of the drivers impacted loaded than it does to just update the kernel.
sippingabonedry 7 hours ago [-]
Sorry but I'm not causing outages and rebooting systems every four days because the people whose job it is to do this can't triage properly. They are actively making other's lives more difficult. There's like 100 CVEs in that list and not a one of them is important to most systems. Even worse, if there was 1/100 it's a needle in a haystack.
Gigachad 6 hours ago [-]
If your system goes down to update a kernel then you have a major issue already. This is like manually renewing https certs. When the task is done often enough you just automate it in a painless way.
sippingabonedry 6 hours ago [-]
There is more to the real world than running webshit behind VM clusters.
Real businesses still run legacy file/print services, license daemons, proprietary applications. Some still run on bare metal.
You need outage windows. You can't just YOLO it and update prod during the day, it's unbelieveably irresponsible.
anal_reactor 4 hours ago [-]
Well then, it's a business decision to accept the risks. IMO it makes sense that a percentage of machines would always be offline for maintenance. If you're running bare metal and you cannot afford 10% of your machines being offline at most times, then you're in deep shit if there's even a tiny traffic irregularity, and it's a sign that your management is YOLOing the company. Not uncommon though.
john_strinlai 6 hours ago [-]
severity on cve is a crapshoot most of the time, but especially with linux cna. i would not advise relying on them for decision making.
"We can not assign severity
[...]
So any group that attempts to give a “severity score” to a Linux CVE is lying to you, UNLESS they know exactly your use case.
ALWAYS ignore any attempt that groups such as NIST/NVD that purport to assign things like CVSS scores to a vulnerability. Those numbers are false and give companies a “fake sense of security”."
Weekly? 12 or 24hr cadence for upgrades isn't that crazy in some places for cluster hosts...
SubiculumCode 5 hours ago [-]
Infinite bugs, or limited supply that can be extinguished. That is the question.
hashstring 2 hours ago [-]
Greg KH said this week in his talk at Kernel Recipes: yes CVEs are increasing, no reason to panic, a lot of the LLM CVE fear mongering is overstated [1].
This is a more valuable insight/signal than a CVE enumeration, especially given that Linux CVEs are literally assigned to any bugfix (as others explained as well).
I recently learned that EFI shims are also vulnerable. Is Coreboot the way forward for system security?
baq 5 hours ago [-]
Why would coreboot be safe from AIs which solved Navier-Stokes
imoverclocked 9 hours ago [-]
Is there a way to know if a particular vanilla kernel has a particular CVE addressed? Unhelpfully, the ChangeLog-* only seems to contain sporadic references to CVEs.
crtasm 9 hours ago [-]
Clicking them here lists specific kernels, is that enough to tell you?
"Several" feels a bit of an understatement, there are 1313 CVEs listed on that page!
Wonder how many of these NSA and others been sitting on, for how long and how many are still there? I guess the silver lining with the aixplosion of CVEs is that software eventually will get more secure.
zahlman 5 minutes ago [-]
I checked out the last (highest-numbered) one just as a quick sanity check:
> In the Linux kernel, the following vulnerability has been resolved:
> usb: typec: ucsi: unregister debugfs entries on teardown
> ucsi_register() creates per-instance debugfs entries, but
> ucsi_unregister() keeps them around until ucsi_destroy().
> Drivers like ucsi_glink that unregister/register the same UCSI
> instance across remoteproc restart then try to create an already
> existing debugfs directory and log:
> debugfs: 'pmic_glink.ucsi.0' already exists in 'ucsi'
> Unregister debugfs entries as part of ucsi_unregister(), and
> clear ucsi->debugfs after freeing it so repeated unregister
> paths remain safe.
I'm going to need someone to explain how that could possibly become a "vulnerability".
SchemaLoad 9 hours ago [-]
Something to keep in mind is the Linux project registered as an authority to create their own CVE numbers in 2024. Previously the majority of bugs would just be fixed without note unless there was a demonstration that it could be exploited.
Now they just give almost every bug a CVE number.
rurban 6 hours ago [-]
In one the latest CCC kernel security talks, Ilya van Sprundel estimated 20.000 unfixed Linux bugs sitting around still. It's coming closer.
vdfs 9 hours ago [-]
Any kernel bug gets a CVE even if it's not really a vulnerability or can be exploited
crispr245 8 hours ago [-]
NSA allegedly used to have a "black budget" of around a couple dozen million dollars for software sabotaging. I wonder what percentage of those CVEs could be related to it...
tclancy 8 hours ago [-]
“A couple dozen million” feels like there should be an Imperial measurement for it à la hogshead or furlong.
jaimex2 9 hours ago [-]
s/discovered/fixed
radicalcentrist 2 hours ago [-]
I assume both? I'd be surprised to see a vulnerability fixed without first being discovered.
infthi 2 hours ago [-]
Technically possible if some obsolete code was deleted but later a historical snapshot was analyzed
None of that makes sense. CVEs from two years ago and the Debian bug referenced is a Wireguard VXLAN issue from last year.
jeffbee 9 hours ago [-]
Linux has never, at any point in history, lacked flaws that could be exploited to escalate privileges. The only question has been how well-known the flaws were, and when. The count of latent local privilege escalation bugs has never been zero.
zahlman 4 minutes ago [-]
Seems like a reasonable assumption, but a pretty strong assertion. How could anyone possibly know?
snvzz 6 hours ago [-]
As a reminder: Millions of LoCs that run in supervisor mode. This is what Linux is.
It is not possible to fix all the bugs. This is simply not doable.
The solution has to be fundamental.
The microkernel multiserver system architecture, with a formally verified microkernel. Nothing else can guarantee enforcement of anything.
In practice, this is the same as saying seL4[0], because there are no alternatives.
Related: The seL4 summit 2026 vids are finally up[1].
History has proven that the microkernels are not necessarily more secure and have their own unique set of problems (see: macOS).
hn_submit 5 hours ago [-]
MacOS is not a microkernel, but a hybrid. It's therefore neither secure nor fast.
fdefilippo 3 hours ago [-]
[flagged]
ofjcihen 10 hours ago [-]
[dead]
10 hours ago [-]
SadErn 9 hours ago [-]
AI is finishing the job that Snowden started. If we backfill all these holes privacy can be preserved.
autoexec 4 hours ago [-]
All the good backdoors have got to be in the hardware anyway. There's only a handful of companies making the chips all our systems run on. US companies that can be forced to backdoor their stuff under secret gag orders. I mean, I'm not saying that PSP/CSME subsystems are backdoors, but if I were going to force companies to add one, it'd probably end up looking similar. The blackbox wireless chipsets in all our phones also come from a very small number of companies.
rockskon 5 hours ago [-]
We're in an uneasy truce with regards to mandatory backdoors.
They're not demanded because targets are just so easy to pop.
If we did secure software across the board with AI, there'd likely be a resurgence of calls for mandatory backdoors.
oridjeicjejdj 6 hours ago [-]
Love the optimism.
exabrial 6 hours ago [-]
Fighting fire with fire... Thank you claude:
Roughly 140 CVEs are in areas an unprivileged user might reach: net/sched, netfilter, bpf, io_uring, mm, kvm.
About 850 CVEs are in drivers or filesystems. Those usually need specific hardware, a mount, or root.
On Debian, many of the 140 also need user namespaces. Debian also blocks unprivileged bpf by default.
The above three paragraphs were made up by a non-deterministic computer program. I wouldn't take them as gospel.
globnomulous 6 hours ago [-]
> Don't post generated text or AI-edited text. HN is for conversation between humans.
That was a human posting a count of issues generated by an ai... not an ai generated message? Or do all the issues need to be counted by hand now ?
autoexec 4 hours ago [-]
Anyone here who wanted an unreliable summarization from a chatbot could have just asked a chatbot for one. If the count/breakdown of issues is important to someone, it's probably important to them that it's accurate. That means they'll have to take the time to verify it properly anyway.
3 hours ago [-]
birdsongs 2 hours ago [-]
[dead]
nairboon 5 hours ago [-]
The underlying question is: has a human counted and classified those 140 issues? Or is that information the output of LLM?
5 hours ago [-]
baq 5 hours ago [-]
Thank you globomulous for disincentivizing people from responsible AI use disclosures.
autoexec 4 hours ago [-]
People who are respectful enough to disclose their use of AI in the first place will hopefully be respectful enough not to fill this space with AI slop after being informed/reminded that it isn't welcome.
baq 3 hours ago [-]
I can only reiterate what a sibling comment says: are we supposed to count cves by hand?
theteapot 6 hours ago [-]
Did the non-deterministic computer program provide any references?
exabrial 5 hours ago [-]
I instructed it to not violate any robots.txt or cause any sort of floods. As such it did a general sweep without pulling the full texts or doing a complete analysis. I’d use it as a rough guide.
My take is that we didn’t see 1000+ easily exploitable RCEs.
>“Due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel… Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify.”
https://docs.kernel.org/process/cve.html
"number of cves" is a useless metric, especially when it comes to the kernel.
If you're willing to stretch, missing but planned features also deny the use of said features since they haven't been added yet, and so are CVSS 1/Low vulnerabilities.
Resume-driven development for security researchers has never been easier!
However, the Linux kernel is supposed to run any userland program without crashing, so anything that crashes the kernel is a local DoS and there are a lot of them. It's also supposed to shield processes from each other and maintain privilege levels correctly, so many incorrect memory leaks are also CVE worthy. Whether a CVE applies depends on the people and programs using the kernel, and the kernel team can't read your code to tell you if it applies or not.
People reading CVEs wrong ("it's got a high number so we must patch within a day") must be going crazy over this, but the point of CVEs is to let you make judgement calls, not to be a cool statistic about how secure something is.
Most CVEs are irrelevant to most people, that's always been the case.
Unpatched bug, wrong color lights.
Yes, it is a bit of a stretch, I desperately hope programmable navigation lights are not a thing. And I also don't think every bug needs a CVE. But in the correct context nearly any bug could be critical.
Now this was a windows system[2] rather than linux but the point remains - if there was an external vulnerability in a crucial control system and this system was part of a network (eg to connect telemetry) then any exploit of that system could result in loss of life.
[1] https://www.computerweekly.com/news/1280091718/Chinook-compu...
[2] Which, why? Why build the fuel controller for a helicopter engine on windows?There have been documented problems with Windows for Warships.
That doesn't follow. In the extremely simple example, an adding service returning 1+1=3 has a bug, but it's not a possible DoS situation at all.
> missing but planned features also deny the use of said features
That's not what DoS is.
This whole situation with CVE assigning comes from the whole process being far from ideal. But it doesn't mean it's completely useless and doesn't follow any rules at all.
Until someone finds there is a user input they can trigger this bug causing some other bit of code to read data from the wrong offset and now it's a whole exploit.
https://daniel.haxx.se/blog/2026/06/24/a-cve-dispute/
Any patch that is back ported to a stable kernel, indiscriminately. And they have also started assigning CVSS scores with the same kind of malicious compliance.
Take for example, this patch in the device mapper RAID code:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
After back porting to stable, it got assigned CVE-2026-89558 (which is in this list), and a CVSS score of 9.8:
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree...
Reasoning behind it being that theoretically, a RAID could be accessible over the network via NFS, iSCSI, etc... so if it gets corrupted, the buggy code path in the recovery (CVE-2026-89558) is effectively triggered over the network.
I do find it interesting though, that in the interest of transparency, every bugfix gets a CVE. Which ends up being a huge number… which will ultimately yield a more insecure environment as we’re getting conditioned to ignore/discount CVEs by the volume.
Over-reporting in this case seems to risk being counterproductive.
Kernel development is well-funded, both via grants and by direct employment at big tech companies, and if they wanted to properly triage and annotate vulnerabilities, and provide reasonable assessments of what is or isn't likely to be a security risk, they absolutely could. They almost certainly could go to Google and say "we need two people full-time on your payroll for this" and they would get it.
I don't want to dunk on them too much because they're generally doing God's work, but these absolutist security stances are not worth being taken seriously.
It's basically saying that they can't possibly provide a valuable service for 99.999% of the install base because there might a hypothetical person out there using Linux in a really weird way. If Microsoft tried to make an argument like that, they'd get crucified.
Linux only ever wanted to promise support for the latest release and even Linux LTS is a concession.
And CVEs are basically a useless concept if you roll. (or at least not any more useful than any other bug tracker which supports tags)
If he kept true of his "we don't break user space" instead of it being "we don't break user space until we do and then it's on you to deal with it" perhaps more people would be willing to run the latest release.
I would argue that it is more productive for the enduser as well. Not making a decision they cannot reasonably make is better then blindly believing in a decision that is likely wrong for your usecase.
The frequency and severity of cyber attacks has increased to the point a much more cautious approach has become common. It's also easier to sell this work to management when you can point at the security tab on some tool and say "Look we need to patch these CVEs"
:-P
The user may have no idea that the plugin is malicious; the program remains bug-free (if it was beforehand).
Er what?? CVEs should be assigned to bugs, not bugfixes, right?
this is a good outcome. A forcing function to encourage all computing to be more secure can only be good in the long term, even if there's a lot of pain in the short term.
They're definitely a useful additional tool for finding more (and more obscure) bugs, but that takes a lot of both human and compute effort too, and after the reports are clean you still can't be sure if all bugs were found.
The important thing to remember here is there perfect isn't on the table. The benchmark is existing human-introduced bugs vs LLM-introduced bugs. Many developers have encountered odd bugs which a human would not have introduced, while forgetting about all the bugs caught which humans introduced. Or their opinion is formed by models from six months ago.
Fortunately there are people who write software for fun so there will always be some people who would rather do it themselves.
It's not magic and it's not even better or even as good as a mid human, but it's something like infinite man-hours of that drudge work per hour per user.
That will find a lot in old code, and make it a lot easier to keep on finding every little thing right as it's created in new code.
And, of course, there are piles of legacy corporate spaghetti entangled in incomprehensible mess everywhere you look at. And this shit still runs, this precious hand-carved hand-weaved mess of bad decisions. I can't wait for LLMs to rewrite most of it.
Want to merge the PR? I need verified sign off in ServiceNow by staff level engineer. They are on vacation for 2 weeks? Did manager fill out delegation paperwork in ServiceNow with VP sign off? Oh they did but they forgot to put in return date AND time. Form needs to be corrected and reapproved before we can go into ServiceNow and make changes.
That may be true. Serious question though: even if most devs wanted to develop formally verified code, do you think that it is reasonable to suggest that the typical systems developer could do it with today's tools? I don't mean verified protocols (TLA+) or verified algorithms (SPIN) I mean end-to-end verified code, a-la seL4. I got the impression that this is still very specialised work. Perhaps things have advanced since I last checked.
I recently asked it to review my code and configs from the security perspective. Wow! 90% of the things it identified were MY bad decisions dating from pre-AI development. I am honestly humbled and impressed at the same time.
AI can create slop, and it can create quality products. It depends who is using it, and how.
I'm not super sure about that. But if its going to exist I'm crossing my fingers it works to the OSS community benefits (eventually)
We knew that for long time, there are countless meme about it, smart people protected their asses from it or exploited those.
It was "load bearing" just fine....
Anything is "fragile" if you put a bulldozer over it....
That’s what I did with Safebox: https://safebots.ai/about/infrastructure.html
1. LLMs have high false positive rate. From mythos 79 vulnerabilities found in the Linux kernel, only a single digit were actual bugs and they were all obscure so don’t panic.
2. What does obscure mean? I don’t really understand it, but many of the bugs have to do with custom network drivers or other custom drivers that are very specific to certain organizational setups, not a general Linux distro issue.
3. He’s very frustrated with the high false positive rate mythos generates. Even after multiple rounds of adversarial review and prompting strats, he mentions it is > 20% false positive rate, which wastes a lot of time. When some random user on the internet brings up a bug with an LLM it’s almost always fake, he even says just push back a few times claiming it’s not a bug to see if it’s a real bug (LLMs very quickly cave and “notice their mistake” etc)
4. General observation on the useful bugs mythos finds. Chain multiple smaller bugs to see if you can get a bigger breakage. Mythos is really good at constructing these long convoluted chains that fuzzers miss.
5. Go through recent bug fixes and check if similar bugs are hidden elsewhere in the codebase. Mythos is good at such pattern matching albeit with a high false positive rate.
Final conclusion: don’t panic, the bugs are getting fixed, this is not as bad as the first fuzzer bug mania and will be fixed quicker, he estimates a year and we won’t see huge bug reports anymore.
Extending the ratio from my other comment. What are the token ratios between using LLMs to:
1. Create functional software
2. Find bugs in functional software
3. Triage/Prioritise a quadrupling of the reported CVEs
4. Fix the bugs while keeping the software functional
I'm assuming that #2, #3, and #4 require more tokens (each or cumulatively) that #1, then there will be increase in the amount of insecure software because, with the advent of LLMs (that allow otherwise non-software developers to become software developers), there will be (a lot?) more software being created.
If we want software security to get better, then the existence of LLMs requires the increasing use of LLMs. I find this quite interesting.
Even with AI there's an asymmetry separating 'functional' from 'secure'.
As with software development prior to AI, security has a cost associated with it, and unless there are _real_ consequences, it's a cost that most software houses ain't gon' pay.
Good to see someone say this. Software need only be good enough to do the job, and only as safe as reasonably required. Systems can be secured and audited through other means, sometimes at lower expense than guaranteeing every line of software has zero risk associated.
It was always the case that finding vulnerabilities in software was easier than writting perfect software. I'm hopeful that we can use AI to make software more secure over time. Project Zero [1] and others has shown many times the past few years (pre LLMs) that automated fuzzing and other forms of dynamic analysis are very effective, which bodes well for automated testing via LLMs!
I agree that more code = more bugs overeall, but there are slow moving codebases that run some of the worlds most valuable software. Seems like using AI to find vulnerabilities in that code is a huge win across the board.
[1]: https://www.google.com/search?q=site%3Aprojectzero.google&q=...
I was speaking in the general sense, not of these vulnerabilities specifically. I am of the view that AIs for the foreseeable won't produce code that is any better from a security point of view than something human written, so AIs will produce new vulnerabilities at least as fast as they find them and the rest of us will be faced with massive headaches like the one in the original post.
> It was always the case that finding vulnerabilities in software was easier than writting perfect software. I'm hopeful that we can use AI to make software more secure over time. Project Zero [1] and others has shown many times the past few years (pre LLMs) that automated fuzzing and other forms of dynamic analysis are very effective, which bodes well for automated testing via LLMs!
And yet, we are not seeing a drop-off in new vulnerabilities being discovered. We keep assuming that the list of bugs is getting smaller and we'll find them all eventually, but that is not the case for any software that I know of.
> I agree that more code = more bugs overeall, but there are slow moving codebases that run some of the worlds most valuable software. Seems like using AI to find vulnerabilities in that code is a huge win across the board.
It might be, yet, as I said just above, we are not seeing a drop-off in new vulnerabilities being found. The trickle of vulnerabilities has become a flood across all open source software, and already breakages and problems are occurring as maintainers struggle to keep up. Administrators, likewise, are struggling to keep systems updated. Just a week or so ago a security patch to rsync on RHEL broke rsync so completely that it could no longer handle symbolic links.
Critical CVEs used to be relatively infrequent, but they're becoming a weekly or even daily occurrence. None of us are prepared for this eventuality.
If you simply prompt them to produce code, with the same kind of processes that humans use, then yes, of course. After all, it trained on human code.
If you prompt them explicitly to spend time looking for vulnerabilities and not implementing new features, then why wouldn't it produce more secure code? If we're calling the technology a "force multiplier", then it's thus for every task it can perform. So, orient the process around that; avoid the compromises that were originally motivated by working at human speed (, interest level, fatigue, specialization, …)
Of course, if you see places where the application of artificial "intelligence" can benefit from human wisdom, then double down on that. (Quotes because I think the term is fundamentally inaccurate for what it refers to, even though it's typically good enough and refers to a useful capability.)
AI regurgitating all the insecure code AI companies scraped from stack overflow and github isn't going to give you something too different from what the humans who put it there in the first place came up with. Garbage in, garbage with random hallucinations out.
I forget to add the obvious: some garbage gets through despite the mitigations. In the limit of pure garbage input, you'll get a model that internalized garbage generation. And you'd be better off throwing it away and starting over.
Also I find calling millennium problem solutions ‘straightforward’ baffling, to be polite.
Furthermore, you need to make sure the model you use is capable enough to review your code comprehensively enough. That includes for both basic vulnerabilities but also attack chain related vulnerabilities.
It's not enough, though, to just tell the model to check the code for vulnerabilities. The model has to be guided specifically to look for particular classes of problem and that takes someone experienced in security.
But, does that all of these being found now call into question, not the open source model logic itself, but the ability of human eyes to find security issues? These vulnerabilities have been sitting here for however long, but how many thousands of humans did not find them before AI?
For Linux, the threshold is nearer to the point of it being questionable whether a bug is even exploitable on a real production distro, compiled and run with any sort of sane configuration.
Like everything in CS, apparently this is a trade-off, not an absolute. You can get bug-free code, but it's not commercially viable and is extremely tedious to do.
https://www.eng.auburn.edu/~kchang/comp6710/readings/They%20...
When asked, people prefer €15 burger no tip, but when actually making a choice, they prefer €10 burger with €5 tip. Similarly, companies state "bug-free code" as a goal or requirement, but then they prioritize other goals over code correctness. My workplace is in the process of completely removing code reviews. And actually, I don't disagree with the decision - my career is short, but I have never seen reviews fulfill any purpose other than to share the blame in case of an incident.
It's incredibly problematic for many reasons, but it finds bugs in C really well.
Also there are likely a lot of vulnerabilities identified but the work required to fix them vs the complexity to exploit them means they don't get fixed.
I'd wager we don't have an issue with identifying vulnerabilities but the ability to fix them.
I work in security consulting and identifying vulnerabilities isn't the difficult part its actually fixing them and fixing the ones that have valid exploitable attack chains that matter
Long term I suspect that the purpose of the digital domain is going to end up being rethought. For instance connecting critical infrastructure to the internet has always been a terrible idea, and LLMs will just make that even more clear.
On the iphone for example even if you find a crippling bug in iOS which gives you full root access, there is still no way to get the device encryption key or face ID info because the secure enclave simply has no electrical connection that can pass that key to the OS.
Wouldn't this mean people are actually encountering issues where there are none before? Likely some serious enough that they lead to exploits where there weren't before? Where are the reports of these new defects?
And this is the best of cases. I fear many times in a smaller projects it was “it compiles at last, let’s see if anybody complains”. That’s why LLM’s are so damn effective today.
(been there, done that – I’m not pointing fingers, but we are human, we get tired, and we don’t have the NASA budget to complete things and ship them)
Remotely or locally exploitable? This is very lacking on information.
However I see software variants where simple numbers work as well, e.g. Firmware code that runs on totally self contained hardware is often just versioned with simple integers, that is because most updates (releases) of that software contain both features and bugfixws and "breaking changes" don't apply to stuff that doesn't read or write files. So you could use semver and have 1.50.0, 1.51.0, 1.52.0 forever, but by that point you can just give it aimple integer versions.
I suggest this post be renamed “A legion of vulnerabilities has been discovered…”
one again illustrating the importance of encapsulating unsafe behavior. perhaps c should get a __UNSAFE { } block, where memory access is encapsulated and thus most bugs occurring outside of those blocks do not need to be marked as CVEs.
I think the convention for this is at the filesystem level and most programmers use the `.c` suffix to indicate it
perhaps we could call it a sedimentchest?
Apparently by late summer this year, there were already more vulnerabilities found than in all of 2025.
Seems like an enormous increase over 2024 and 2025.
There are good reasons for QNX becoming viable again in the automotive world. Linux / Android has so many vulnerabilities that it needs indefinite patching, which is unrealistic for any computing device but cars especially. Car makers are switching to QNX even though it costs them money.
Weren't there rumours that intelligence agencies have been using microkernel operating systems for decades?
My car runs QNX for its infotainment/navi system but I had the impression that manufacturers were, sadly, moving away from QNX?
[0] https://forum.qubes-os.org/t/qsb-116-multiple-xen-issues-xsa...
P.S.: QNX is a general purpose OS as well and runs on PCs, ARM and a myriad of other architectures. Same holds for MINIX and Sel4.
Governments, military, aviation, space.
For a good portion of the usage, the people involved cannot even talk about it. But sometimes it's possible. A surprising amount of real world use showed up in talks in seL4 summit 2026[0].
0. https://www.youtube.com/playlist?list=PLd7rrADYxxQQ
The government isn't telling anyone about it because they don't want to sink a multi-trillion dollar corporation.
These get released every few weeks. Tons of CVEs. If a kernel developer farts in the forest, does anyone hear it?
August saw separate Debian kernel updates released four days apart. Does anyone even reboot that often?
I have three kernels installed over the last 45 days or so and I probably missed a few.
>Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team are overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team.
https://lwn.net/Articles/961961/
Microsoft kinda got this right by doing it once a month, unless it's something horribly bad, you can plan your maintenance around a predictable calendar.
You can skip the Xanax this week.
Real businesses still run legacy file/print services, license daemons, proprietary applications. Some still run on bare metal.
You need outage windows. You can't just YOLO it and update prod during the day, it's unbelieveably irresponsible.
"We can not assign severity
[...]
So any group that attempts to give a “severity score” to a Linux CVE is lying to you, UNLESS they know exactly your use case.
ALWAYS ignore any attempt that groups such as NIST/NVD that purport to assign things like CVSS scores to a vulnerability. Those numbers are false and give companies a “fake sense of security”."
http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignmen...
This is a more valuable insight/signal than a CVE enumeration, especially given that Linux CVEs are literally assigned to any bugfix (as others explained as well).
[1] https://youtu.be/NnV_cWeoo5Q
https://security-tracker.debian.org/tracker/source-package/l...
Searching around, the best I have found so far for vanilla kernels is: https://linuxcvetracker.com
It does require a little clicking around to get all the info I want though. Time to pull out curl+awk! :)
Wonder how many of these NSA and others been sitting on, for how long and how many are still there? I guess the silver lining with the aixplosion of CVEs is that software eventually will get more secure.
> In the Linux kernel, the following vulnerability has been resolved: > usb: typec: ucsi: unregister debugfs entries on teardown > ucsi_register() creates per-instance debugfs entries, but > ucsi_unregister() keeps them around until ucsi_destroy(). > Drivers like ucsi_glink that unregister/register the same UCSI > instance across remoteproc restart then try to create an already > existing debugfs directory and log: > debugfs: 'pmic_glink.ucsi.0' already exists in 'ucsi' > Unregister debugfs entries as part of ucsi_unregister(), and > clear ucsi->debugfs after freeing it so repeated unregister > paths remain safe.
I'm going to need someone to explain how that could possibly become a "vulnerability".
Now they just give almost every bug a CVE number.
alternative link, clearer source: https://lists.debian.org/debian-security-announce/2026/msg00... (https://news.ycombinator.com/item?id=49891411)
It is not possible to fix all the bugs. This is simply not doable.
The solution has to be fundamental.
The microkernel multiserver system architecture, with a formally verified microkernel. Nothing else can guarantee enforcement of anything.
In practice, this is the same as saying seL4[0], because there are no alternatives.
Related: The seL4 summit 2026 vids are finally up[1].
0. https://sel4.systems/
1. https://www.youtube.com/playlist?list=PLd7rrADYxxQQ
They're not demanded because targets are just so easy to pop.
If we did secure software across the board with AI, there'd likely be a resurgence of calls for mandatory backdoors.
Roughly 140 CVEs are in areas an unprivileged user might reach: net/sched, netfilter, bpf, io_uring, mm, kvm.
About 850 CVEs are in drivers or filesystems. Those usually need specific hardware, a mount, or root.
On Debian, many of the 140 also need user namespaces. Debian also blocks unprivileged bpf by default.
The above three paragraphs were made up by a non-deterministic computer program. I wouldn't take them as gospel.
https://news.ycombinator.com/newsguidelines.html
That was a human posting a count of issues generated by an ai... not an ai generated message? Or do all the issues need to be counted by hand now ?
My take is that we didn’t see 1000+ easily exploitable RCEs.