alt Hacker NewsSeveral vulnerabilities have been discovered in the Linux kernel
Comments
Just the beginning. AI is going to expose how fragile the entire computing infrastructure in our world is.
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.
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?
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!
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.
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?
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.
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.
Are these primarily AI-assisted findings ?
Seems like an enormous increase over 2024 and 2025.
Pretty much any kernel bug gets a CVE by default now, right?
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)
Infinite bugs, or limited supply that can be extinguished. That is the question.
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?)
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.
I recently learned that EFI shims are also vulnerable. Is Coreboot the way forward for system security?
"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.
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.
None of that makes sense. CVEs from two years ago and the Debian bug referenced is a Wireguard VXLAN issue from last year.
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].
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.
[dead]
AI is finishing the job that Snowden started. If we backfill all these holes privacy can be preserved.
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.