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.”
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!
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.
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.
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.
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.
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.
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"
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.
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
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?
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
> 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?
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.
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.
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…”
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
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.
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)
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?)
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.
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...
>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.
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.
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.
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.
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”."
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.
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.
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.
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.
"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.
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.
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...
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.
Just the beginning. AI is going to expose how fragile the entire computing infrastructure in our world is.
Does this also mean the code generated and reviewed by LLMs will not have such issues going forward?
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.”
https://docs.kernel.org/process/cve.html
"number of cves" is a useless metric, especially when it comes to the kernel.
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!
> 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.
>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.
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.
Why couldn't a crash caused by filesystem corruption caused by a + operator that says 1+1=3 be filed as a DoS?
It's not hard to imagine an application for which 1+1 = 3 leads to security issue.
> 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.
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.
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.
Let's say they do and only 5% are "security issues" you still need to update either way.
They chose to do it this way, in. part, because CVEs were already like that, and too many people were pretending they weren't.
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"
With particular emphasis on "almost any bug might be exploitable".
Even a bug-free program might be exploitable.
That sounds like a bug
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.
At that point you're exploiting the user, who is not a bug-free program
But if you squint, it might be a bug in the system to allow access to that program.
That's also not exploiting the program, it's exploiting the user.
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.
> Don't post generated text or AI-edited text. HN is for conversation between humans.
https://news.ycombinator.com/newsguidelines.html
Did the non-deterministic computer program provide any references?
https://www.cve.org/CVERecord?id=CVE-2024-52560
https://www.cve.org/CVERecord?id=CVE-2024-58094
etc.
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
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?
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.
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.
No one is smart enough to write bug free in any language.
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.
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.
https://www.eng.auburn.edu/~kchang/comp6710/readings/They%20...
Clearly it’s because people never got the memo: https://www.rfc-editor.org/rfc/rfc9225.html
That's why we designed better languages that can block the compilation if memory hasn't been handled properly.
The difference is that C casually makes common everyday bugs into security vulnerabilities.
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.
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.
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.
I believe they call it semantic versioning (SemVer).
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.
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!
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.
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.
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.
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.
> 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?
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.
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.
If they were bugs of consequence you could expect each one to get it's own domain with a scary name and a logo.
Unfortunately no, there are a lot more that fly under the radar.
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.
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.
1,313 vulnerabilities, to be precise.
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…”
Are these primarily AI-assisted findings ?
Seems like an enormous increase over 2024 and 2025.
Yes, naturally. It’s a brave new world.
Pretty much any kernel bug gets a CVE by default now, right?
Is that all there is here? The quantifier "several" did not prepare me for the wall of CVE numbers in this list.
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
Yes. It looks funny, but it's a nothing burger.
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.
> 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
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?
See xkcd's sandboxing cycle. They exist, they're called processes
I think that’s just called “memory”. Encapsulation is your machine.
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)
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?)
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.
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.
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...
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.
https://lwn.net/Articles/961961/
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.
You can choose to only install updates that require a restart once a month on Debian, then it's the same.
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.
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.
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.
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”."
http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignmen...
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.
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.
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.
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 exceedingly irresponsible.
Weekly? 12 or 24hr cadence for upgrades isn't that crazy in some places for cluster hosts...
I recently learned that EFI shims are also vulnerable. Is Coreboot the way forward for system security?
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.
Clicking them here lists specific kernels, is that enough to tell you?
https://security-tracker.debian.org/tracker/source-package/l...
That's useful if you run a Debian-packaged kernel.
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! :)
You can script around https://git.kernel.org/pub/scm/linux/security/vulns.git/ (which is likely what the page you linked use)
"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.
In one the latest CCC kernel security talks, Ilya van Sprundel estimated 20.000 unfixed Linux bugs sitting around still. It's coming closer.
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.
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...
“A couple dozen million” feels like there should be an Imperial measurement for it à la hogshead or furlong.
Any kernel bug gets a CVE even if it's not really a vulnerability or can be exploited
None of that makes sense. CVEs from two years ago and the Debian bug referenced is a Wireguard VXLAN issue from last year.
Title is: Debian alert DSA-6528-1 (kernel)
alternative link, clearer source: https://lists.debian.org/debian-security-announce/2026/msg00... (https://news.ycombinator.com/item?id=49891411)
s/discovered/fixed
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.
AI is finishing the job that Snowden started. If we backfill all these holes privacy can be preserved.
Love the optimism.