|
|
Log in / Subscribe / Register

Stable kernels 6.12.2, 6.11.11, and 4.19.325

Greg Kroah-Hartman has released the 6.12.2, 6.11.11, and 4.19.325 stable kernels. Note that both 6.11.11 and 4.19.325 are the last kernels in those series, "please move off to a newer kernel version". In the 4.19.325 release notice, he has a rather longer-than-usual message, including:
As a "fun" proof that this one is finished (and that any company saying they care about it really should have their statements validated with facts), I looked at the "unfixed" CVEs from this kernel release. Currently it is a list 983 CVEs long, too long to list here.

You can verify it yourself by cloning the vulns.git repo at git.kernel.org and running:

	./scripts/strak v4.19.325
Note, this does NOT count the hardware CVEs which kernel.org does not track, and many are sill unfixed in this kernel branch.


to post comments

6.12 being LTS (as expected - but not labeled) - 4.19 now EOL (as former LTS - with hints to go directly to 6.12 LTS) ...

Posted Dec 5, 2024 16:01 UTC (Thu) by JMB (guest, #74439) [Link] (7 responses)

It is interesting that www.kernel.org still marks 1.12.1 as stable
and not yet as longterm - and GKH notes 6.12 as LTS in 4.19.325
announcement to persuade people still using this LTS to directly
jump to the latest LTS with is now fresh in 6.12.2 ...
so extremely early ...

Maybe there is a lot of problems to differentiate between
security (which is always not being determined in a real quantity)
and reliability which is matter of experience ...
This no criticism ... just thoughts ...

6.12 being LTS (as expected - but not labeled) - 4.19 now EOL (as former LTS - with hints to go directly to 6.12 LTS) ...

Posted Dec 5, 2024 17:03 UTC (Thu) by ballombe (subscriber, #9523) [Link]

... because it is the available version likely to be supported for the longest time I gather.

But do not trifle with Linux 1.21.2: this version never existed!

6.12 being LTS (as expected - but not labeled) - 4.19 now EOL (as former LTS - with hints to go directly to 6.12 LTS) ...

Posted Dec 5, 2024 17:21 UTC (Thu) by alspnost (guest, #2763) [Link] (2 responses)

Note that as of today, 6.12 is now listed in the longterm release table, with the same end of life as all the other recent LTS versions: i.e., Dec 2026. So there are currently no "ultra life" kernels with a projected lifetime beyond 2 years.

Lack of ultra-LTS kernels

Posted Dec 6, 2024 9:07 UTC (Fri) by DemiMarie (subscriber, #164188) [Link] (1 responses)

A corollary of LTS kernels only being supported for 2 years is that any product containing Linux and supported for longer than that will need one or more major kernel upgrades over its life. I hope this will force more upstreaming of drivers.

Lack of ultra-LTS kernels

Posted Dec 6, 2024 12:46 UTC (Fri) by joib (subscriber, #8541) [Link]

Why can't they just backport fixed themselves anymore? Like most distros with long term releases have been doing since forever?

6.12 being LTS (as expected - but not labeled) - 4.19 now EOL (as former LTS - with hints to go directly to 6.12 LTS) ...

Posted Dec 6, 2024 9:56 UTC (Fri) by bojan (subscriber, #14302) [Link] (2 responses)

6.12.2 got replaced by .3 in short order. I hope it fixes the hang on Hyper-V.

6.12 being LTS (as expected - but not labeled) - 4.19 now EOL (as former LTS - with hints to go directly to 6.12 LTS) ...

Posted Dec 6, 2024 15:12 UTC (Fri) by easwarh (subscriber, #131924) [Link] (1 responses)

What hang on Hyper-V? Is there a bugzilla or mailing list report for that?

6.12 being LTS (as expected - but not labeled) - 4.19 now EOL (as former LTS - with hints to go directly to 6.12 LTS) ...

Posted Dec 6, 2024 19:35 UTC (Fri) by bojan (subscriber, #14302) [Link]

CVEs

Posted Dec 5, 2024 17:23 UTC (Thu) by alspnost (guest, #2763) [Link] (4 responses)

If all the thousands and thousands of patches that have continued to be applied since the original 4.19 release are not fixing CVEs, what are they fixing? So the CVE list is nearly a thousand for this kernel - is it zero for the latest LTS (i.e., now 6.12.2)? Presumably not?

CVEs

Posted Dec 5, 2024 17:56 UTC (Thu) by eean (guest, #50420) [Link]

probably fixing other CVEs

CVEs

Posted Dec 5, 2024 19:17 UTC (Thu) by ballombe (subscriber, #9523) [Link]

Does the tool account for vulnerabilities that were introduced after 4.19 was released ?

CVEs

Posted Dec 6, 2024 2:36 UTC (Fri) by kazer (subscriber, #134462) [Link] (1 responses)

Other CVEs and issues that were not given a CVE tracking in the first place.

CVEs

Posted Dec 6, 2024 2:51 UTC (Fri) by kazer (subscriber, #134462) [Link]

Let me clarify this by saying that developers fix and improve things all the time and later someone might figure out that it also fixed a thing that might have been a security issue as well. Greg gave an interesting talk about this recently.

CVE

Posted Dec 6, 2024 9:21 UTC (Fri) by daeler (subscriber, #130460) [Link] (4 responses)

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

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.


Copyright © 2024, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds