432 Linux kernel CVEs published in the last 24 hours
38 points by Helithumper
38 points by Helithumper
Periodic reminder that a CVE is not the same thing as a vulnerability. A CVE is an identifier that can be attached to a vulnerability, in the case that a vulnerability is actually discovered.
Sorry, but I don't follow. Perhaps this was meant as a general reminder, but these are vulnerabilities.
The CVE IDs were assigned by the kernel devs, after review. They even mention the fixes for each.
I realised too late that you probably meant that the title should read "432 Linux kernel vulnerabilities."
Sorry!
The Linux kernel project has repeatedly said they consider most bugs for CVEs.
http://www.kroah.com/log/blog/2026/01/02/linux-kernel-security-work/
http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process/
TL;DR: If it's not a performance fix, a hardware bug fix, a filesystem corruption etc.. then it's probably a CVE candidate.
Greg K-H gets at this when talking about how the kernel security team doesn’t know how the kernel is being used in all cases (and the discussion of warn is a great example) but he doesn’t quite call out the way this is a weird artifact of the way the naming system works and the fact that the kernel has become its one CNA (CVE naming authority).
When the CVE system got started, it was really meant for “products” as opposed to components you use to build products. So it’s something of a weird fit for a thing like an OS kernel that’s used in many different kinds of products in many different ways. From that perspective, it’d be better if, say, CachyOS, the people who make a camera that embeds the kernel, and Red Hat independently processed whether a bug was a CVE candidate or not. One bug might be a security problem in need of a CVE name for the camera, but not in Red Hat or in CachyOS.
But then you’d get CVEs for 300 cameras, 300 weird file-serving routers that take unusual actions when you insert an USB stick, and several dozen retro game emulation consoles that do the same with SD cards.
So it’s better for the overall ecosystem if we camp it at the component, even if the way the CVE system is structured makes that weird.
From the first one re: xfs:
The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log.
Is this practical? It seems like crafting such a log to exploit this vulnerability would require taking the filesystem offline and writing to the block device storing the log directly. So either having root or physical access and the ability to power down the system. Am I misunderstanding something about the xfs log?
Even if that's not a threat to properly configured servers that don't automount USB drives / SD cards and have video surveillance and monitoring if someone powers them down, it could still affect people running Linux in different contexts. E.g. giving someone an SD card with "photos" and when they plug it in at home, it actually contains a malicious XFS file system that triggers an exploit chain. I think mounting a file system should be a safe operation, like opening an image file.
Things being unlikely doesn't mean it's not a potential vulnerability. Also the context matters - maybe some kiosk-style device automounts drives when they are plugged in? It's often not practical... until someone finds a stack of issues or context where it is.
Plug USB or HDD into a server at a colocated hosting site? I imagine 95% success rate. Sure, you are on a camera, but nobody can see clearly that you are not plugging something into a different server in the same rack.
I couldn’t resit and asked a LLM to create catchy names for each CVE: https://git.infradead.org/~rw/cvenames-2026-07-19.html