So CopyFail CVE-2026-31431 is a thing.
-
@Di4na @joshbressers @gregkh @deftpunk @Viss
Yes, the fact that the official advisory said
Update your distribution's kernel packageandMost major distributions are shipping the fix nowwhen not a single distribution on the planet had an updated kernel package is evidence that the whole publication was a "Look at us!" vehicle, and everybody else on the planet be damned!I can't say that it's a lie because I can't prove that they knew it was wrong.
Side wonder: Can something written by AI never be called a lie?
@wdormann @joshbressers @gregkh @deftpunk @Viss mostly yes, which is also why I refuse to call it hallucinations or other anthropomorphizing statements... because it just aggregates words together that sounds like they work together.
-
-
@joshbressers @wdormann @deftpunk @Viss What do you mean, they told us, we fixed it, it got in some stable kernels, and so our work on the security team was done. The CVE team assigned a CVE after a while, and even gave it a CVSS score.
The fact that no distro popped up that used older kernel versions to do the real work to backport to older kernels seems to be everyone's major problem here. That is outside of the kernel security team's work entirely. So take it up with the distros that people are paying support for to do this for them?
And yes, Debian was vulnerable, that is not good, and once it was noticed people worked hard and quickly to fix that. Not bad for a community-based distro that no one pays for in my opinion. -
@gunstick
The original (and current) CVE entry is merely the commit message.Which is unintelligible nonsense for anyone other than a Linux kernel developer.
@wdormann exactly.
If it would say CVSS 7.3 more eyes would have looked (distro maintainers).
If it says "exploit to root available" even more eyes would heve looked.
Instead it is just technobabble to align the dilithium crystals, so nobody knows what it means. -
@joshbressers @wdormann @deftpunk @Viss What do you mean, they told us, we fixed it, it got in some stable kernels, and so our work on the security team was done. The CVE team assigned a CVE after a while, and even gave it a CVSS score.
The fact that no distro popped up that used older kernel versions to do the real work to backport to older kernels seems to be everyone's major problem here. That is outside of the kernel security team's work entirely. So take it up with the distros that people are paying support for to do this for them?
And yes, Debian was vulnerable, that is not good, and once it was noticed people worked hard and quickly to fix that. Not bad for a community-based distro that no one pays for in my opinion.@gregkh @deftpunk @wdormann @Viss
You said this wasn't reported to the kernel security team
From where I sit (and I'm not in the middle of this) it seems like if you plan to make a website and give something a name, tell the securiy team
If you're OK with the current process though I shall trust you on this, you're the expert, I'm just the peanut gallery
-
@gregkh @deftpunk @wdormann @Viss
You said this wasn't reported to the kernel security team
From where I sit (and I'm not in the middle of this) it seems like if you plan to make a website and give something a name, tell the securiy team
If you're OK with the current process though I shall trust you on this, you're the expert, I'm just the peanut gallery
@joshbressers @deftpunk @wdormann @Viss the "announcement of a public web site and exploit" was not sent to the kernel security team. If you look at the timeline they published, they show what they sent the kernel security team and when, which seems to be correct to me. -
@alcastronic
"Good" is a weird way to describe something that only works on some distributions.@wdormann
With "good", I was referring to RHEL's proposal that requires a reboot to become effective. -
@joshbressers @deftpunk @wdormann @Viss the "announcement of a public web site and exploit" was not sent to the kernel security team. If you look at the timeline they published, they show what they sent the kernel security team and when, which seems to be correct to me.
-
@joshbressers @wdormann @deftpunk @Viss What do you mean, they told us, we fixed it, it got in some stable kernels, and so our work on the security team was done. The CVE team assigned a CVE after a while, and even gave it a CVSS score.
The fact that no distro popped up that used older kernel versions to do the real work to backport to older kernels seems to be everyone's major problem here. That is outside of the kernel security team's work entirely. So take it up with the distros that people are paying support for to do this for them?
And yes, Debian was vulnerable, that is not good, and once it was noticed people worked hard and quickly to fix that. Not bad for a community-based distro that no one pays for in my opinion.@gregkh @deftpunk @joshbressers @wdormann @Viss How did 'The CVE team assigned a CVE after a while' work? I see the docs say it's the reporters job to tell the CVE team; but hmm that CVE assignment was ~3 weeks after the fix went in mainline - is there something that could help there? e.g. did linux-security give the CVE guys a nudge, or remind the original reporters they needed to do that?
-
@gregkh @deftpunk @joshbressers @wdormann @Viss How did 'The CVE team assigned a CVE after a while' work? I see the docs say it's the reporters job to tell the CVE team; but hmm that CVE assignment was ~3 weeks after the fix went in mainline - is there something that could help there? e.g. did linux-security give the CVE guys a nudge, or remind the original reporters they needed to do that?
@penguin42 @deftpunk @joshbressers @wdormann @Viss I honestly don't remember, and if I did, we don't publish who asked for CVE ids from us as that's generally not a good idea to do so (and is not a requirement for being a CNA). -
@penguin42 @deftpunk @joshbressers @wdormann @Viss I honestly don't remember, and if I did, we don't publish who asked for CVE ids from us as that's generally not a good idea to do so (and is not a requirement for being a CNA).
@gregkh @deftpunk @joshbressers @wdormann @Viss Hmm OK - tbh I think that gap to the CVE being issued is the biggest thing here (says he on the outside), if that was issued earlier I think there would have been a better chance a distro might have noticed. So perhaps if linux-security makes sure it reminds reporters to do it, and also asks them to give you a heads up before any announcement that might have helped here.
-
@joshbressers @wdormann @deftpunk @Viss What do you mean, they told us, we fixed it, it got in some stable kernels, and so our work on the security team was done. The CVE team assigned a CVE after a while, and even gave it a CVSS score.
The fact that no distro popped up that used older kernel versions to do the real work to backport to older kernels seems to be everyone's major problem here. That is outside of the kernel security team's work entirely. So take it up with the distros that people are paying support for to do this for them?
And yes, Debian was vulnerable, that is not good, and once it was noticed people worked hard and quickly to fix that. Not bad for a community-based distro that no one pays for in my opinion.@gregkh @deftpunk @joshbressers @wdormann @Viss I think we (the distro security teams, speaking as a member of the Debian one) would have liked a heads up, including maybe to help backporting to the stable kernel we run. We didn't have that heads up, we discovered the thing like everyone else.
-
@gregkh @deftpunk @joshbressers @wdormann @Viss I think we (the distro security teams, speaking as a member of the Debian one) would have liked a heads up, including maybe to help backporting to the stable kernel we run. We didn't have that heads up, we discovered the thing like everyone else.
@gregkh @deftpunk @joshbressers @wdormann @Viss
As Greg mentioned, vulnerability coordination is difficult, and it's hard to draw a line about who to include and who not to.
Maybe the researchers thought they did the right thing by notifying the kernel security team (and they did), and they thought it was enough. But I don't think it's written anywhere that the kernel security team will coordinate with downstream (or anyone else), and again I'm not sure it's really possible.
-
@gregkh @deftpunk @joshbressers @wdormann @Viss
As Greg mentioned, vulnerability coordination is difficult, and it's hard to draw a line about who to include and who not to.
Maybe the researchers thought they did the right thing by notifying the kernel security team (and they did), and they thought it was enough. But I don't think it's written anywhere that the kernel security team will coordinate with downstream (or anyone else), and again I'm not sure it's really possible.
@gregkh @deftpunk @joshbressers @wdormann @Viss
Still, it leaves a bit of a bitter taste. Not sure how we can do better though. -
@wdormann @joshbressers @Viss I love it how people think that "coordination of vulnerabilities" is actually something that can be done these days. Think of just who uses the software in question, and who should, and should not, be on such a list to get a "early disclosure notification".
As I have said for quite some time now, all early-disclosure lists are leaks, otherwise why would your government allow them to be in existence?
Software, and specifically open source software, runs the world. So should the whole world be on that notification list?
@gregkh @joshbressers @wdormann @Viss so there's absolutely no middle ground? When there is clearly a bug with security impact, give the distros list a week notice (two weeks max, per their policy). If it leaks, outcome is no worse than not notifying distros. The researcher can even do it instead of the kernel. At scale (Linux!) this seems like a Pareto distribution: major distros cover disproportionally most users.
-
@gregkh @deftpunk @joshbressers @wdormann @Viss
Still, it leaves a bit of a bitter taste. Not sure how we can do better though.@corsac
> Not sure how we can do better thoughA random idea, not sure how far it is from what you already do:
Bump automation where packages from latest stable branches are built and available with no human intervention in specific repositories. Manual promotion for generic repos should be as effortless as possible. -
@corsac
> Not sure how we can do better thoughA random idea, not sure how far it is from what you already do:
Bump automation where packages from latest stable branches are built and available with no human intervention in specific repositories. Manual promotion for generic repos should be as effortless as possible.@Aissen The process is already pretty scripted but there's still some manual things to do (whether in the kernel packaging or in the DSA processing).
On Apr 30th v6.12.85 was tagged at 1116Z and the DSA was sent at 2005Z. I'm unsure we can do much faster.
note: I didn't do anything this time, it's mainly the work of Salvatore Bonaccorso (as a volunteer): https://salsa.debian.org/kernel-team/linux/-/merge_requests/1895
-
@letoams @CliffsEsport
Up-to-date Fedora (42 or later) are not affected at the time of publication (Yesterday).
At least on this Fedora 42 system, the kernel was built on April 23 and in stable 2 days ago. Not a few hours ago.@wdormann weird because I had a successful test on up to date f42 yesterday …
-
@wdormann weird because I had a successful test on up to date f42 yesterday …
@letoams
Got a snapshot that you can revert to?
I'd like to see the evidence (along with showing the current kernel version). -
@gregkh @joshbressers @wdormann @Viss so there's absolutely no middle ground? When there is clearly a bug with security impact, give the distros list a week notice (two weeks max, per their policy). If it leaks, outcome is no worse than not notifying distros. The researcher can even do it instead of the kernel. At scale (Linux!) this seems like a Pareto distribution: major distros cover disproportionally most users.
@zmanion @joshbressers @wdormann @Viss Why is linux-distros somehow "special" enough to get these types of announcements and not everyone else? How exactly would you explain that to your favorite government entity?
