On 29/04/2026 21:23, Jan Schaumann wrote:
Affected and fixed versions
===========================
Issue introduced in 4.14 with commit
72548b093ee38a6d4f2a19e6ef1948ae05c181f7 and fixed in
6.18.22 with commit
fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8
Issue introduced in 4.14 with commit
72548b093ee38a6d4f2a19e6ef1948ae05c181f7 and fixed in
6.19.12 with commit
ce42ee423e58dffa5ec03524054c9d8bfd4f6237
Issue introduced in 4.14 with commit
72548b093ee38a6d4f2a19e6ef1948ae05c181f7 and fixed in
7.0 with commit
a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
https://git.kernel.org/stable/c/fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8
https://git.kernel.org/stable/c/ce42ee423e58dffa5ec03524054c9d8bfd4f6237
https://git.kernel.org/stable/c/a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
So this is one of the worst make-me-root vulnerabilities in the kernel
in recent times. I see that on the 11th of April 6.19.12 & 6.18.22 were
released with the fix backported.
Longterm 6.12, 6.6, 6.1, 5.15, 5.10 have not received the fix and I
don't see anything in the upstream stable queues yet as I write. My
guess is backporting that far back is not as straightforward. As this
was introduced in 2017 all those older kernels are affected, right? Or
am I missing something?
If so, this is no reflection on Greg and Sasha, it's not up to them to
produce backports, they have enough of a job co-ordinating stable
releases for so many kernels, which I see them do an amazing job of week
in, week out. Evidently no one produced the needed backports?
IIUC many installations with these older kernel could already be
protected by now, in an ideal world.
What went wrong, has the embargo been broken early today? Not looking to
point any fingers, those who make things happen in our communities work
dam hard and deserve respect and support, especially with the extra
burden of AI slop now.
Eddie
