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

  commented:
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!

  commented:
Any interesting ones?

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

  commented:
arguably, a filesystem corruption bug could also be considered a CVE
candidate tbh

  commented:
I guess you did not read the second link, which mentions this.

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

  commented:
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?

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

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

  commented:
Many of these read: "In the Linux kernel, the following vulnerability
has been resolved:"
.