Over 400 Linux CVEs published in the last 24 hours alone

https://lore.kernel.org/linux-cve-announce/

by aghuang • 1 day ago

76 41 1 day ago

lore.kernel.org

traceroute663• 1 day ago

Might need to silently archive those Microsoft Patch Tuesday jokes...

AdmiralAsshat• 1 day ago

Don't worry, Microsoft is still leading:

https://www.bleepingcomputer.com/news/microsoft/microsoft-ju...

1970-01-012• 1 day ago

Those that actually understood security, and weren't on some kind of open-source enforcement mission in life, always knew the "Linux doesn't get viruses" statements would not age well.

https://blog.desdelinux.net/en/virus-in-gnulinux-reality-or-...

traceroute663• 1 day ago

Those that actually understood security....

Indeed, and those who actually understood software development always knew vulnerabilities can occur just as easily as bugs.

And in some cases more easily than bugs, because many of modern vulnerabilities are so subtle, especially where crypto is involved.

kvuj• 1 day ago

You should be careful not to conflate viruses and CVEs.

Considering no Linux distro come with an antivirus by default, Linux as a desktop was always extremely vulnerable to bad actors.

As a server, I would argue otherwise.

gosub100• 1 day ago

If they were there this whole time but only discovered now, were they really a threat? The reflexive response to this is "those could be exploited for years and we'd never know", but if it was discovered, it obviously wasn't impacting you personally. If they were under lock and key at the NSA and only judiciously used for secret spy BS, that's effectively the same as not existing. Clearly they weren't discovered by all the white hats for this whole time.

Also, if Microsoft hypothetically open sourced their code, do you think there would be more, less, or the same number of CVEs? I would guess more.

I don't want to go too far to defend Linux. I want to make the case that it has been the more secure OS this whole time.

traceroute663• 1 day ago

I want to make the case that it has been the more secure OS this whole time.

Your phone is ringing, caller ID says its Theo de Raadt from OpenBSD. :)

csande17• 1 day ago

https://docs.kernel.org/process/cve.html

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

(And because this happens during the stable release process, there are a lot of 24-hour periods where they issue a ton of CVEs for all the minor bugs fixed in the release.)

alhirzel2• 1 day ago

I am assuming that many of these are found with automatic analysis tools that are very creative (i.e. LLMs) and there may be a high proportion of very "cornered" cases. I think there needs to be a triage method that would amount to the severity, likeliness, and detection dimensions used to rank risks in a systematic framework [1]. I think if this could be submitted (or estimated) along with such bug reports, it could go a long way toward sustainable intake patterns for this number of possible defects.

[1] https://en.wikipedia.org/wiki/Failure_mode_and_effects_analy...

petra303• 1 day ago

In my company, the security team isn’t technical. They see CVE, find a vulnerable system, it gets flagged. We have to patch it.

We patched for a CVE last week that a malicious usb sound card device could be use the gain root.

On a Vm? Is that something we really need to worry about??

dboreham• 1 day ago

It's asymmetric warfare. It costs them little to demand a false positive be acted upon, but costs you plenty to refute it.

chelmzy• 1 day ago

Its the same at most orgs. Very rare for a vuln remediation program to utilize a truly risk based approach. They would have to trawl through and understand thousands of vulns and the context of your org. There's probably a market for some tool to accomplish this if the larger players haven't attempted already.

lousken• 1 day ago

They see their dashboard, when the number is high, they want to get the number low as fast as possible. If the number is close to zero, they want to see zero. It is that simple.

They do not care if the issue is in a piece of code that is never executed and would require full access to the machine. It is there and tool X reports it.

Even security audits are terrible, when they don't find anything major they start reporting stuff that few percent of companies have implemented just to stuff their reports, it is ridiculous.

thewebguyd2• 1 day ago

This is the rot that's happening in cybersec. Before we even had security teams as a dedicated role, sysadmins mostly handled security, and we would evaluate each CVE and determined if it even was applicable.

Then companies started hiring paper pushers into security roles and discretion no longer mattered, it just became a game of "Check the box" with no regard for what is actually running in prod, or whether you're actually vulnerable.

Same shit with auditors. I deal with PCI and it's a fight to explain why the "compensating controls" work to a non technical auditor. If it doesn't check the box exactly, good luck.

jerf• 1 day ago

I only sampled them, but all the ones I sampled are announcements of fixes, not just vulnerabilities. This seems to be downstream of the "intake" already.

bob0012• 1 day ago

The linux kernel team disagrees with your approach but what do they know?

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

pixl97• 1 day ago

That with LLMs being decent at chaining exploits suddenly very difficult issues can be accomplished by people with middling abilities and resources.

alhirzel2• 12 hours ago

I was too busy waxing my armchair and didn't do any reading on the actual practices. Thank you for replying with this. It makes sense. I wonder if this level of purity will survive the test of time; since there are paid kernel developers, the situation could be very different from e.g. an entirely volunteer-maintained project.

PedroBatista2• 1 day ago

Linus better put his money where mouth is and fire up those AI tokens ASAP.

I don't consider this a tragedy, it's just unearthing the reality.

juliangmp• 1 day ago

What does any of this have to do with AI?

PedroBatista2• 1 day ago

There has been a long discussion and "conflict" of opinions regarding the use of AI in kernel dev.

Linus is pro-AI as a tool ( and I mostly agree, there are consequences however that at least need to be talked about ). That's why I was talking about firing up those AI machines and fix those CVEs ( "make no mistakes" ).

But it seems every Linux topic related to security or languages is the ultimate mine field for knee-jerk reactions. :)

st_goliath• 1 day ago

I guess very few around here remember the minor fuzz about this from a few years ago? The Linux Kernel Project became their own CNA (CVE Numbering Authority). A CVE is now slapped onto practically every bug fix that is back ported to a stable kernel, resulting in a flood of CVEs.

A blog post about this, published at the time: https://sigma-star.at/blog/2024/03/linux-kernel-cna/

The title is editorialized (i.e. the OP made it up), the link simply goes to the kernel CVE mailing list archive.

altairprime• 1 day ago

(Email the mods to clear up the editorial title problem; footer contact link.)

pseudohadamard• 15 hours ago

It's malicious-compliance CVE filing. Other interesting coverage of the issue by Risky Biz, https://news.risky.biz/risky-biz-news-the-linux-cna-mess/.

Given the broken nature of the CVE process, see for example Daniel Stenberg of cURL fame's frequent comments on this, I'm undecided whether this is a good thing, a bad thing, or a bit of both.

OsrsNeedsf2P• 1 day ago

Amazing how people think this means anything

rvz2• 1 day ago

This sounds like cope.

We are going to see more of this with LLMs being able to uncover hundreds of bugs in projects just like Linux.

devmor• 1 day ago

This has nothing to do with LLMs.

theK• 1 day ago

CVE-2026-64012: net/sched: sch_sfb: Replace direct dequeue call with peek and qdisc_dequeue_peeked.

You are right, its over.

On a more serious note. Yes and no. The kernel is secure. It is probably the most scrutinized piece of software in existence. LLMs will find things but most probably they just will help contributors fix bugs.

catigula• 1 day ago

Chinese models, hurray!

bob0012• 1 day ago

You do realize this is an announcement of already fixed issues which were fixed (and not just flagged) weeks or months ago, right? Or are you claiming that Chinese models allow for time travel?

rwz• 1 day ago

Good, it seems like new AI tools would lead to substantially more hardened Linux kernel long term. Until a new generation of AIs finds more bugs.

khurs• 1 day ago

All these seem to be by the same person.

Go Greg!!

https://en.wikipedia.org/wiki/Greg_Kroah-Hartman

http://www.kroah.com/linux/

insanitybit• 1 day ago

What people are missing is that these aren't vulnerabilities. The reason you see this is because Greg does not believe in the CVE system. As an act of rebellion, the Linux kernel (a) assigns CVEs to fixes and not bugs, (b) assigns them gratuitously to DoS the system.

This is just Greg being a baby. Linux has to be removed as a CNA ASAP, it was a terrible idea to ever grant them that power.

This has nothing to do with AI or even security.

sloped• 1 day ago

More useful context http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignmen...

Nothing to panic about.

SAI_Peregrinus• 1 day ago

Nearly every bug is at best a denial of service. If the service worked as expected, there wouldn't be any bug. CVSS considers any denial of service a security issue. Therefore, all bugs should have CVE numbers. The Linux team took this to heart, became a CNA, and assigns CVEs to pretty much every bug.

boeroboy• 9 hours ago

More fuel for the Asterinas kernel, coming for Linux with a purely Rust kernel.

minraws• 4 hours ago

This should be considered unethical tbh.

Over 400 Linux CVEs published in the last 24 hours alone

Related Stories