My point is that it is not representative of the current state of the kernel.
The kernel has nothing to do with Ubuntu, its release schedule and LTS's. Distro LTS releases also often mean custom kernels, backports, hardware enablement, whatnot, which makes it a fork, so unless were analyzing Ubuntu security rather than Linux security, mainline should be used.
Mitigations are generally kernel workarounds, not microcode updates. Microcode updates provide some fixes or disable features, but all kernel efforts and why they specify the software at all is because of kernel mitigations.
The problem is that it's downstream backports and hardware enablement - you're running an old forked artisinal kernel maintained by Canonical, you will only get bugfixes if known to be severe enough to be flagged, and all this patching deviates it from mainline and can itself introduce new security vulnerabilities not present in mainline.
This differs from an actual later release which is closer to mainline and includes all newer fixes, including ones that are important but weren't flagged, and with less risk of having new downstream bugs.
If you're going to fight pedantism by being pedantic, better be the right kind of pedantic. ;)
It is up to date, with security patches and fixes. That is obviously what is relevant here. That is why the parent comment got down voted, since it is up to date in context of a security vulnerability.
It should be even more secure, since new software versions might introduce unknown attack vectors.
I am saying that any version of Ubuntu is not representative of the mainline kernel, which is what is relevant when it comes to analyzing current mitigations.
Distro LTS releases often mean custom kernels, backports, hardware enablement, whatnot, which makes it effectively a fork.
Unless were interested in discovering kernel variation discrepancies, its more interesting to analyze mainline.
I'd expect an awful lot of production workloads to be running on LTS kernel versions (and likely also LTS distro releases). So the mitigations currently available in an LTS release of a mainstream distro are quite relevant.
They are running their LTS distro's LTS kernel, but that us not an upstream thing
On an LTS, you'll be running a Canonical kernel, or a Red Hat kernel, or a SuSE kernel, or an Oracle kernel, or...
Each will have different backports, different hardware enablement, different random patches of choice, and so different bugs and problems.
Unless were evaluating the security of a particular distro release, mainline is what is Linux and will ultimately be the shared base for future releases.
24.04 is an LTS (long term support) release, so it receives updates, including security updates, for much longer than a regular release. I believe it's a 5-year support window, and longer if you shell out for paid support.
These updates mean that you are no longer running a mainline kernel, but an Ubuntu fork with whatever backports and hardware enablement (and new bugs!) this might introduce. This is also true for other software.
LTS does not mean you get all updates, it only means you get to drag your feet for longer with random bugfixes. Only the latest release has updates.
This only matters if the mainline kernel since then somehow experienced changes which would affect this hardware vulnerability (fixed through microcode), which I see no indication of?
CPU vulnerabilities are first fixed through kernel mitigations, only sometimes through microcode.
But security research should be done against the current state. Something as simple as a performance optimization can end up affecting the exploitability, and while that doesn't change whether the CPU is vulnerable it does change the conclusion.
Evaluering if a particular old, forked codebase is security-wise is identical is a fools errand, and then that doesn't answer whether an equivalent Red Hat kernel is vulnerable as that's a different fork with different backports and local patches. Mainline is the shared base.
I don’t quite understand how that matters here. The researchers found a CPU vulnerability. They demonstrated it on a popular Linux distribution and LTS version, Ubuntu 24.04. They likely picked that to show that the attack is not purely theoretical, but feasible on something that real users currently use for real things. There is a microcode fix available that solves this problem, presumably across all OSes and releases. Whether the kernel is current and how much it diverges is, frankly, irrelevant.
They are not just looking for vulnerabilities, they're demonstrating impact which is kernel dependent.
The kernel has numerous CPU bug mitigations that change kernel behavior to make the CPU bug ineffective for active exploitation (microcode rarely fixes bugs other than just disabling a whole subsystem - they usually take silicon iterations to fix, and the kernel has to pick up the slack), and current kernel design choices may also unintentionally render the vulnerability ineffective.
That's why they specifically say what OS and version they're running, exactly because it is crucial. It's just that they are not, in fact, up to date when it comes to the kernel.
So not very up to date, but I suppose mitigations haven't changed significantly upstream since then.