CVE

Posted Dec 6, 2024 9:21 UTC (Fri) by daeler (subscriber, #130460)
Parent article: Stable kernels 6.12.2, 6.11.11, and 4.19.325

That's interesting I assumed that a supported kernel would include fixes for known CVE's. Thanks for clearing that up.

to post comments

CVE

Posted Dec 6, 2024 12:27 UTC (Fri) by simon.d (guest, #168021) [Link] (1 responses)

Yep, I'm also a bit confused by that.

CVE

Posted Dec 7, 2024 23:21 UTC (Sat) by MaZe (subscriber, #53908) [Link]

An awful lot of the work is done 'best effort' and/or for free... People will flag patches as fixes when they upstream them into Linus' tree, which will automatically get them cherrypicked into supported LTS'es, but if they don't cherrypick cleanly, they'll likely just get skipped (unless the conflict resolution is absolutely trivial) by the LTS maintainers. A lot of developers will not do the extra work (to manually resolve the conflicts), unless there's devices they use that are running an old affected kernel. For me personally that used to mean 5.10+ but it now finally means 6.1+.

Additionally sometimes security fixes are in userspace, but build on kernel functionality (think LSM, sandboxing, etc), and older kernels may simply lack the required support. Usually these fixes just don't function (and effectively self disable) if they run on too old kernels. Imagine something that locks stuff down tighter using BPF LSM - if the kernel is too old to support BPF LSM, it simply won't do anything.

Then you've got people taking the 4.19 LTS and backporting it to the no longer support 4.14 LTS as unofficial extended LTS [ for example https://github.com/openela/kernel-lts/tree/linux-4.14.y ], but these are even more of a lie than the now abandoned 4.19 was.

CVE

Posted Dec 6, 2024 19:55 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

> I assumed that a supported kernel would include fixes for known CVE's

I think the work they've been putting in on tracking bug fixes with security implications has helped make plain the simple truth that this _isn't_ happening, people aren't backporting _all_ known fixes and applying them to older kernel.org LTS releases, which is something the core kernel devs are intimately aware of but have had miserable luck in communicating with downstream developers over the decades. Issuing their own CVE tracking has lifted the wool off some people's eyes as to the real state of the kernel.

CVE

Posted Dec 9, 2024 8:42 UTC (Mon) by taladar (subscriber, #68407) [Link]

I really don't think this is a kernel specific issue but a general flaw in the idea of LTS versions receiving backports.

The amount of effort required to literally backport every fix is just not sustainable, especially for the longer LTS support times where the user base shrinks significantly and is often mostly comprised of Enterprise customers who want to pay as little as possible while demanding to be treated entirely differently from everyone else (i.e. the people sticking to relatively up to date versions no older than a year or two at most).

Not to mention that the stability, the whole reason for staying on an old version, becomes a bigger and bigger lie the more backports introduce changes to the old version anyway.