Rendered at 02:13:49 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
john_strinlai 1 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.
theteapot 5 minutes ago [-]
I've been following these announcements for a few years. This is the most CVEs I've seen in one by a wide margin, although there have been some big sets coming through for things like chromium, openssl. I agree it's mostly meaningless without context. So what's the context? Who/what found all these bugs?
SAI_Peregrinus 1 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!
viraptor 7 minutes 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.
rerdavies 1 hours ago [-]
With particular emphasis on "almost any bug might be exploitable".
SoftTalker 32 minutes ago [-]
Even a bug-free program might be exploitable.
catlifeonmars 27 minutes ago [-]
That sounds like a bug
SoftTalker 14 minutes 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 9 minutes ago [-]
At that point you're exploiting the user, who is not a bug-free program
Fordec 53 minutes 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 34 minutes 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.
SchemaLoad 50 minutes 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 49 minutes ago [-]
No one is smart enough to write bug free in any language.
zakisaad 43 minutes 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.
That's why we designed better languages that can block the compilation if memory hasn't been handled properly.
wat10000 12 minutes ago [-]
The difference is that C casually makes common everyday bugs into security vulnerabilities.
0c3ca83 10 minutes ago [-]
AI levels the playing field; it's incredibly good at finding the bugs.
tetrisgm 2 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 2 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 19 minutes 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 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.
catlifeonmars 20 minutes 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.
drfloyd51 1 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 56 minutes 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 54 minutes 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 47 minutes 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...
sippingabonedry 40 minutes ago [-]
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 27 minutes ago [-]
You can choose to only install updates that require a restart once a month on Debian, then it's the same.
SoftTalker 30 minutes 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 23 minutes 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.
seany 12 minutes ago [-]
Weekly? 12 or 24hr cadence for upgrades isn't that crazy in some places for cluster hosts...
userbinator 1 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.
walrus01 43 minutes 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.
SchemaLoad 1 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 1 hours ago [-]
Unfortunately no, there are a lot more that fly under the radar.
modeless 3 hours ago [-]
1,313 vulnerabilities, to be precise.
nathell 1 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…”
BobbyTables2 2 hours ago [-]
Are these primarily AI-assisted findings ?
Seems like an enormous increase over 2024 and 2025.
ganelonhb 1 hours ago [-]
Yes, naturally. It’s a brave new world.
50 minutes ago [-]
sva_ 2 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.
DominoTree 2 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)
thallium205 2 hours ago [-]
Pretty much any kernel bug gets a CVE by default now, right?
wjholden 2 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 1 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
seba_dos1 1 hours ago [-]
Yes. It looks funny, but it's a nothing burger.
slopinthebag 2 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 2 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
slopinthebag 1 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 18 minutes ago [-]
I think that’s just called “memory”. Encapsulation is your machine.
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 1 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.
crispr245 27 minutes 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...
SchemaLoad 1 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.
vdfs 1 hours ago [-]
Any kernel bug gets a CVE even if it's not really a vulnerability or can be exploited
9 minutes ago [-]
jaimex2 1 hours ago [-]
s/discovered/fixed
jeffbee 1 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.
SadErn 2 hours ago [-]
AI is finishing the job that Snowden started. If we backfill all these holes privacy can be preserved.
>“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!
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.
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.
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.
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.
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.
Remotely or locally exploitable? This is very lacking on information.
I suggest this post be renamed “A legion of vulnerabilities has been discovered…”
Seems like an enormous increase over 2024 and 2025.
Apparently by late summer this year, there were already more vulnerabilities found than in all of 2025.
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?
alternative link, clearer source: https://lists.debian.org/debian-security-announce/2026/msg00... (https://news.ycombinator.com/item?id=49891411)
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.
Now they just give almost every bug a CVE number.