The Linux Kernel Is Approaching 2,000 CVEs Per Release

The Linux kernel has a very liberal interpertation of what should be a CVE: "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"

For example, looking at this list, the top one is currently CVE-2026-80591 requires corrupted on-disk metadata on the f2fs filesystem. Let me carefully suggest that you've already lost if an attacker can corrupt your filesystem.

This is a "assuming the bank robber has unfettered access to the bank vault, they can pilfer it" type issue. Not really a "security bug" as commonly understood.

It's also very likely literally no one has run in to that bug by the way, and one has to wonder if it's even a bug in the first place.

In general using CVEs to track "security issues" is very flawed because it's gamed so much, but for the Linux kernel even more so.

It may be worse:

- CVE inflation due to Greg assigning them to trivial commits.
- Multiple cases of actual vulnerabilities that don't get assigned a CVE.
- The scores are completely bogus and don't reflect the actual impact.
- The commit messages for the fixes obfuscate the real thing.
- The commits are being sloppily backported to LTS kernels.

This strange behaviour by Greg has been described as malicious compliance.

This is my impression from following the lead of Grsecurity. https://x.com/spendergrsec
 
  • Like
Reactions: mer
Back
Top