There are approximately 488 Linux kernel CVEs per month* and not a lot of reason to think that CVE-2026-31431("copy
-
There are approximately 488 Linux kernel CVEs per month* and not a lot of reason to think that CVE-2026-31431("copy .fail") is particularly special.
- It's an LPE (local privilege escalation). Yes, we should take it seriously and never give up the dream. No, you should not rely on non-virtualized containers to provide a true multi-tenant security boundary.
- Every potential attacker in the world has been able to observe the vulnerability in source code form since mid-2017 (9 years ago).
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee38a6d4f2a19e6ef1948ae05c181f7- The vendor was notified of the vulnerability 2026-03-23 (39 days ago), apparently with enough detail to put together a patch in ~3 days.
- Every potential attacker in the world was informed of the specific vulnerability 30 days ago (2026-03-31 at the latest) when the patch was committed with the header "Reported-by: Taeyang Lee <0wn@ theori. io>" Theori .io advertises both offensive and defensive security information services on their site.
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/commit/?id=a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5The researchers:
- Notified the kernel security team
- Observed the patch committed
- Waited another 34 days
- Published a detailed writeupProfessionally done, IMO.
The researchers followed the process outlined on the affected vendor's website. Specifically:
"the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL...[list that includes some absurdly vague conditions]"
https://docs.kernel.org/process/security-bugs.htmlTo do much more than follow the vendor's preferred disclosure process often amounts to demanding that *your* bug be given special attention and treatment. Which is a thing researchers sometimes do. Naturally it's hard to be objective about one's own finding.
Assessing and prioritizing bug reports is generally the job of the *vendor's* security team, *not* the researchers. There are exceptions. But to force special handling for your bug is simply to blindly take resources away from all the reports that will lead to the 487 other CVEs that month. And some of those might not be LPEs. They could be wormable remote network holes or virtual machine breakout bugs.
In this case, the kernel security team appears to have decided that the appropriate response was to let downstream read about it when the patch was committed to source control like everybody else. A CVE was publicly announced 11 days later, for a total of 30 days after being notified.
There are far worse systems.
Regardless, that process is theirs to manage. It's between the Linux kernel team and whoever they have made promises to.
I don't know about you, but I get my Linux for free. Nobody promised me anything.
* Data from stack .watch/product/linux/linux-kernel/, 14 month average
-
There are approximately 488 Linux kernel CVEs per month* and not a lot of reason to think that CVE-2026-31431("copy .fail") is particularly special.
- It's an LPE (local privilege escalation). Yes, we should take it seriously and never give up the dream. No, you should not rely on non-virtualized containers to provide a true multi-tenant security boundary.
- Every potential attacker in the world has been able to observe the vulnerability in source code form since mid-2017 (9 years ago).
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee38a6d4f2a19e6ef1948ae05c181f7- The vendor was notified of the vulnerability 2026-03-23 (39 days ago), apparently with enough detail to put together a patch in ~3 days.
- Every potential attacker in the world was informed of the specific vulnerability 30 days ago (2026-03-31 at the latest) when the patch was committed with the header "Reported-by: Taeyang Lee <0wn@ theori. io>" Theori .io advertises both offensive and defensive security information services on their site.
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/commit/?id=a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5The researchers:
- Notified the kernel security team
- Observed the patch committed
- Waited another 34 days
- Published a detailed writeupProfessionally done, IMO.
The researchers followed the process outlined on the affected vendor's website. Specifically:
"the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL...[list that includes some absurdly vague conditions]"
https://docs.kernel.org/process/security-bugs.htmlTo do much more than follow the vendor's preferred disclosure process often amounts to demanding that *your* bug be given special attention and treatment. Which is a thing researchers sometimes do. Naturally it's hard to be objective about one's own finding.
Assessing and prioritizing bug reports is generally the job of the *vendor's* security team, *not* the researchers. There are exceptions. But to force special handling for your bug is simply to blindly take resources away from all the reports that will lead to the 487 other CVEs that month. And some of those might not be LPEs. They could be wormable remote network holes or virtual machine breakout bugs.
In this case, the kernel security team appears to have decided that the appropriate response was to let downstream read about it when the patch was committed to source control like everybody else. A CVE was publicly announced 11 days later, for a total of 30 days after being notified.
There are far worse systems.
Regardless, that process is theirs to manage. It's between the Linux kernel team and whoever they have made promises to.
I don't know about you, but I get my Linux for free. Nobody promised me anything.
* Data from stack .watch/product/linux/linux-kernel/, 14 month average
@marshray I'm following this for the most part, but what I don't understand is why they thought they needed to stand up an entire domain name and website and coordination point, and then ... do almost nothing with it [initially, and for a couple days after].
Either they thought it was important enough to do that, and they therefore have a corresponding obligation to at least minimally coordinate and inform defenders (which is what many named vulnerabilities have done in the past), or ... it wasn't. They've chosen some weird middle ground, and even if it was only for marketing reasons, it sure doesn't make me want to buy their product, because I don't trust them to have the judgment or good taste to understand the implications of what they're choosing to do.
-
@marshray I'm following this for the most part, but what I don't understand is why they thought they needed to stand up an entire domain name and website and coordination point, and then ... do almost nothing with it [initially, and for a couple days after].
Either they thought it was important enough to do that, and they therefore have a corresponding obligation to at least minimally coordinate and inform defenders (which is what many named vulnerabilities have done in the past), or ... it wasn't. They've chosen some weird middle ground, and even if it was only for marketing reasons, it sure doesn't make me want to buy their product, because I don't trust them to have the judgment or good taste to understand the implications of what they're choosing to do.
@marshray Also, they themselves claim that it is no ordinary vulnerability, and should have stood out - making their failure (to initially leverage their position as even a basic clearinghouse for the rush of people who wouldn't find out about it until later) even more questionable.
Again, it's a weird hybrid of "this is really important" with no understanding of how defenders actually operate.
And for all of their claimed AI acumen, they didn't even bother to prompt for what defenders would need to know (until well after the announcement, where it's clear that they scrambled to fill in some gaps).
-
@marshray Also, they themselves claim that it is no ordinary vulnerability, and should have stood out - making their failure (to initially leverage their position as even a basic clearinghouse for the rush of people who wouldn't find out about it until later) even more questionable.
Again, it's a weird hybrid of "this is really important" with no understanding of how defenders actually operate.
And for all of their claimed AI acumen, they didn't even bother to prompt for what defenders would need to know (until well after the announcement, where it's clear that they scrambled to fill in some gaps).
@tychotithonus I just can't see how finding a bug using AI-guided fuzzing techniques obligates a security researcher to include LLM-generated guidance for defenders in their disclosure.
I think defenders can consult their own chatbots if they wish.
-
@tychotithonus I just can't see how finding a bug using AI-guided fuzzing techniques obligates a security researcher to include LLM-generated guidance for defenders in their disclosure.
I think defenders can consult their own chatbots if they wish.
@marshray I mean, sure, there's no obligation - no more than there's an obligation for me to return my shopping cart. But I still do it, because I understand that what I do has effects on others.
-
@marshray I mean, sure, there's no obligation - no more than there's an obligation for me to return my shopping cart. But I still do it, because I understand that what I do has effects on others.
@marshray And, I mean, I get the spectrum of response here, and I'm not trying to push this into "responsible disclosure" territory. But what they did is shaped like defender-friendly high-visibility disclosures, without the substance. It's like they didn't really understand what it's for ... and aped its form with out understanding its essence.
-
@marshray I mean, sure, there's no obligation - no more than there's an obligation for me to return my shopping cart. But I still do it, because I understand that what I do has effects on others.
@tychotithonus In your view, did the discoverers of the 487 other Linux CVEs that month have such an obligation?
Or is it just for those who go out of their way to inform the users of the affected systems?
-
@marshray And, I mean, I get the spectrum of response here, and I'm not trying to push this into "responsible disclosure" territory. But what they did is shaped like defender-friendly high-visibility disclosures, without the substance. It's like they didn't really understand what it's for ... and aped its form with out understanding its essence.
@tychotithonus They took an LPE and made it into the most talked-about vulnerability of the year.
I think they understand the disclosure process quite well.
-
R relay@relay.infosec.exchange shared this topic
