Yeah everything trixie (13) and above has a patch. Bookworm (12) and bullseye (11) are still vulnerable
Okay I have one version of a container escape working.
This relies on the fact that the page cache is shared between containers and host. There’s no isolation whatsoever. So if the container can see the file descriptor for a host file, copyfail works a treat.
Let’s start with a simple C binary with nothing going on. It’s just a target.
Now, we will mount that binary inside of an Alpine container in read only mode.
Then after installing Python and a text editor, we modify the OG CopyFail exploit to target my binary.
Note that it is targeting the path local to the container, not the host.
When I run the exploit, I will indeed get the “Applet not found” error. However, back on the host:
My “Hello World” binary has become a shell invocation thanks to CopyFail.
This is a bit contrived, but it demonstrates that if a container can see a file shared by the host filesystem and get a FD to it, that’s the ballgame.
1 Like
RHEL’s listed mitigation is of course similar to CERNs since they both use Red Hat based distros but RHEL’s also offers some alternative mitigations and mentions impact
Mitigation
Though the affected module cannot be blocklisted, the affected functions themselves can be using the following boot arguments:
initcall_blacklist=algif_aead_initAlternatively, the af_alg interface itself can be blocked:
initcall_blacklist=af_alg_initAs a further alternative, the affected algorithm can be blocked:
initcall_blacklist=crypto_authenc_esn_module_initPlease note that there might be a performance impact for functionality that uses kernel cryptographic functions.
3 Likes
Arch has been patched: CVE-2026-31431 - linux - Arch Linux
5 Likes
JFC this is the measles of vulns.
2 Likes
It looks like Ubuntu is reporting a patch as well:
https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available
TL;DR:
We recommend you upgrade all packages:
sudo apt update && sudo apt upgrade
If this is not possible, the affected component can be targeted:
sudo apt update && sudo apt install --only-upgrade kmod
1 Like
Since the newer announcement is all about kmod as well, it looks to me like this is another set of “we fixed it by disabling the module” updates rather than a kernel upgrade. They released this yesterday, which looks like the same kind of kmod fix: https://ubuntu.com/security/notices/USN-8226-1
I would be happy to be wrong on that, though.
Theori CEO thread, explaining their approach.
(Via Dormann: Will Dormann: "The CEO of Theori / Xint has a [damage-control th…" - Infosec Exchange )
This vulnerability has been listed in the KEV.
2 Likes
RHEL 9 has a patch:
1 Like
Wow, thank you so much for writing that.
It wasn’t clear anywhere else I read about it, until now.
2 Likes
Now RHEL 8, 9, and 10 have patches:
More patches!
Xint has released its demonstration of container escape:
Essentially, this follow the pattern I demonstrated in my lil PoC: shared inode == get out of the container. So if you have a shared inode between containers via the OverlayFS, you can move laterally between containers.
Additionally, runc in Kubernetes is mounted inside the container as read-only from the host.
Anything that triggers a process inside the container suffices, specifically when running
kubectl execin your container, a container restart, or an init step. To make the wait deterministic, Datadog’s PoC overwrites/bin/shin the container with#!/proc/self/exe, so the next time anyone (or anything) execs a shell inside,runcis invoked.
Once the file descriptor for the runc PID is discovered, CopyFail against that results in overwriting runc on the host, resulting in container escape.
2 Likes