Several vulnerabilities have been discovered in the Linux kernel

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.

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. reply: 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!

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? reply: 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.

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

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! reply: 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.

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. reply: 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. reply: Yes, naturally. It’s a brave new world.

Pretty much any kernel bug gets a CVE by default now, right?

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?)

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.

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 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.

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)

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.