copy.fail
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
Hello,
As far as I can tell, the copy.fail (https://copy.fail/) vulnerability (CVE-2026-31431) is still not patched. I am running fully updated Trisquel 12 and the local exploit works.
I fully appreciate that this is not a critical issue for single-user laptop systems but it still can, at least in theory, lead to a remote root exploit if chained with another non-root remote execution vulnerability.
Am I missing something?
Thanks in advance,
Alexander
Known mitigation for Ubuntu:
https://github.com/theori-io/copy-fail-CVE-2026-31431/issues/35#issuecomment-4353529712
General situation of the kernel patch:
https://github.com/theori-io/copy-fail-CVE-2026-31431/issues/35#issuecomment-4353811173
Everything is fine with the GNU Linux-libre 7.0.2. [1]
From CVE-2026-31431 [2][3]:
unaffected from 5.10.254
unaffected from 5.15.204
unaffected from 6.1.170
unaffected from 6.6.137
unaffected from 6.12.85
unaffected from 6.18.22
unaffected from 6.19.12
unaffected from 7.0
[1] https://www.fsfla.org/ikiwiki/selibre/linux-libre/freesh.en.html
[2] https://app.opencve.io/cve/CVE-2026-31431
[3] https://cveawg.mitre.org/api/cve/CVE-2026-31431
Mitigations have landed from upstream, please keep your system up to date.
You can apply this small mitigation command for immediate action,
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf rmmod algif_aead 2>/dev/null
Source: https://copy.fail/
Regards
$ sudo rmmod algif_aead rmmod: ERROR: Module algif_aead is not currently loaded
Does this mean that the system not running algif_aead could not be exploited already?
I read somewhere [1] that the module is dynamically loaded, so if you had not run the first line of the mitigation, any program could load the module, if I understand correctly.
[...] Theori said that it discovered the vulnerability after its researcher, Taeyang Lee, found surface area in the crypto subsystem (specifically, splice() hands page-cache pages and scatterlist page provenance) had been underexplored. [Cont.]
That is about standard methodology in researching vulnerabilities, isn't it?
[Cont.] Using its AI-powered Xint code security tool, the researchers then found the bug after about an hour of scan time. The company said it has also developed an exploit that uses CopyFail to break out of Kubernetes containers. [...]
Is Linux-libre 6.17.0-23 patched for this?
As one user pointed below, it is patched. However the package 'kmod' still contains the disabling file:
$ cat /etc/modprobe.d/disable-algif_aead.conf # Disable algif_aead module due to CVE-2026-31431 (AKA copy.fail) # This will likely be re-enabled in a subsequent update once an updated # kernel has been deployed. # Blacklisting the module isn't sufficient, we need to do as below: install algif_aead /bin/false $ dpkg -S /etc/modprobe.d/disable-algif_aead.conf kmod: /etc/modprobe.d/disable-algif_aead.conf
Another question raised. IF Linux kernels were extremely vulnerable to those privilege escalation attacks, AND Canonical's servers were subject to outage attacks recently, THEN: could it be that Canonical's servers had been exploited through copy.fail before and have been distributing COMPROMISED CODE OR PACKAGES, code that could end up being built and the builds, packaged into within Trisquel repositories and from there redistributed to Trisquel users? Is Canonical ― and Trisquel ― taking measures to avoid that possible catastrophe?
Both supported kernels have already been patched, specifically versions 6.8.0-111 and 6.17.0-23. Interestingly, the 6.8 kernel was updated one day before 6.17, suggesting that Ubuntu prioritizes support for its default kernel throughout the LTS lifecycle.
Besides checking the kernel version, you can verify the fix with the following command: "dpkg -l kmod"
The patched versions are: "31+20240202-2ubuntu7.2" for Trisquel 12 and "29-1ubuntu1.1" for Trisquel 11.
And regarding your other question, don't confuse a Denial with an Intrusion, DDoS attacks are simply the saturation of servers with millions of requests from compromised devices, it doesn't mean that they have "cracked" the Ubuntu servers or data internally.
> The patched versions are: "31+20240202-2ubuntu7.2" for Trisquel 12 and "29-1ubuntu1.1" for Trisquel 11.
Thank you.
> it doesn't mean that they have "cracked" the Ubuntu servers or data internally
Yes, but they could be attempting at least to prevent patching systems worldwide. The first part of the problem applies as a question independently [of] the DDoS attack.