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=a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
The researchers:
- Notified the kernel security team
- Observed the patch committed
- Waited another 34 days
- Published a detailed writeup
Professionally 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.html
To 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
