Skip to content

Commit 8aa63cd

Browse files
garloffgarloff
committed
Security advisory for Linux LPEs copy.fail and Dirty Frag.
Signed-off-by: Kurt Garloff <kurt@garloff.de>
1 parent 45eac80 commit 8aa63cd

1 file changed

Lines changed: 234 additions & 0 deletions

File tree

‎blog/2026-05-10-kernel-root-exploits.md‎

Lines changed: 234 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,234 @@
1+
---
2+
slug: kernel_local_root_exploits
3+
title: Linux Kernel local root exploits CVE-2026-31431, -43284, -43500
4+
authors: [garloff]
5+
tags: [security, linux, cve, copy.fail, dirtyfrag]
6+
---
7+
8+
## Linux root exploits (Local Privilege Escalation) copy.fail and Dirty Frag
9+
10+
Unix is designed as a multi-user system. Different users have their own
11+
files and processes and can work without interference from others.
12+
Linux lives in that tradition. It has advanced the concept with namespaces
13+
where users can also have a private view on networking, process list, filesystems
14+
and other pieces that are traditionally shared (read-only) on a Unix system,
15+
also including some resource management to enhance performance isolation.
16+
17+
It is the operating system's kernel's job to keep the separation safe; in
18+
particular, normal users must not achieve the system administrator (root)
19+
privileges. Where the kernel fails to ensure this, we have a "local root"
20+
vulnerability, a Local Privilege Escalation (LPE).
21+
22+
The Linux kernel is a large and a complex beast. On one hand it has sophisticated
23+
mechanisms to get really good performance out of increasingly complex hardware.
24+
On the other hand, it comes with a huge variety of device drivers. From time to
25+
time, vulnerabilities are found, reported and fixed. The Linux kernel has several
26+
LPEs per year. Most of the time, they affect only a small fraction of users
27+
(typically by being located in a device driver or somewhat exotic feature)
28+
and often they are hard to exploit, needing to win a race condition with
29+
many attempts and sometimes causing crashes in trying (which may not go unnoticed).
30+
31+
We don't report about these LPEs. They get fixed by the upstream Linux kernel
32+
developers, shipped as stable updates by the maintainers and shipped to the end
33+
users via kernel updates from the Linux distributors.
34+
35+
The currently highly visible Linux kernel issues [copy.fail](https://copy.fail/)
36+
and [Dirty Frag](https://github.com/V4bel/dirtyfrag) are both LPEs (local root
37+
vulnerabilities). The reason we report about them is that they both affect
38+
most Linux users and are easy to exploit.
39+
40+
Like [Dirty Pipe](https://dirtypipe.cm4all.com/) and before
41+
[Dirty Cow](https://dirtycow.ninja/), both LPEs rely on improper protection
42+
of the page cache.
43+
The Linux kernel keeps contents from file systems in the page cache; when code
44+
gets executed, it is mapped into your virtual memory. When the memory page is
45+
accessed and not yet loaded into your physical memory, a page fault occurs and
46+
the relevant blocks are loaded from disk — or the access is denied and your
47+
program receives `SIGSEGV` and is terminated. Copying pages is costly and the
48+
kernel avoids it to achieve higher performance. If you write to a memory page,
49+
the kernel may receive a page fault on a read-only mapping (that it created to
50+
avoid copying) and only then do the copy to create a private writable copy.
51+
This approach is called copy-on-write (COW) and is common in modern operating
52+
systems. If a page from the page cache is changed in memory, it is also marked
53+
"dirty", so the kernel knows it needs to write the changes back to the file system.
54+
55+
In copy.fail, the `aead` crypto module did some cryptography in place, avoiding
56+
the need to allocate an extra buffer. Unfortunately, it requires 4 extra bytes
57+
under some conditions; normally aead is used by IPsec and that location is a
58+
designate place in a network buffer. However, a local attacker can make this
59+
write happen to a page cache page by using `splice`. This way, the copy of the
60+
`sudo` binary in the page cache can be overwritten, allowing to circumvent the
61+
safeguards there. The attacker can trivially become root — as the page is not
62+
dirtied, no trace of the corruption will be visible on the disk.
63+
[copy.fail](https://copy.fail/) has been assigned CVE-2026-31431.
64+
65+
In Dirty Frag, a network buffer that is split over several fragments is not
66+
properly handled and the fragmented buffer is not properly COW'ed. The AEAD
67+
crypto operation then again overwrites 4 bytes. A local attacker can trigger
68+
this again become root very quickly by overwriting the page cache's view of
69+
`sudo`. (Of course other sensitive binary code could be overwritten in memory.)
70+
This can be triggered via the IPsec `esp_input` (for both IPv4 and IPv6) as well
71+
as via the `rxrpc` code. The esp variant requires the privilege to create user
72+
namespaces and then allows for easy 4 byte writes at a time. It has been assigned
73+
CVE-2026-43284. The rxrpc variant overwrites 8 bytes, but as these are crypted,
74+
the user needs to brute force them in order to achieve a controlled result. This
75+
variant was assigned CVE-2026-43500.
76+
77+
_Exploiting this vulnerability requires access to the system and the ability
78+
to execute code there, thus the categorization as LPE, not RCE (remote
79+
code execution)._
80+
81+
## Impact
82+
83+
Any system where normal (non-root) users can log in to execute code under their
84+
own control is no longer secure: The users can use the publicly available
85+
exploits to gain root privileges and get access to whatever the (virtual)
86+
machine has access to. This means accessing other user's data as well as secrets
87+
that are stored by the system administrator.
88+
89+
Such systems are less common these days than they were 20 years ago. The reason
90+
is that virtualization has become a commodity, so individual users may use their
91+
own virtual machine rather than having access to a shared (virtual) machine
92+
in many scenarios.
93+
94+
Note that this vulnerability does NOT break the isolation of virtual machines.
95+
VMs remain as securely isolated as they would be without this vulnerability.
96+
These LPEs do NOT establish a virtualization escape.
97+
98+
There is however a common scenario where individual users and workloads
99+
are running inside a container. The LPE also allows for escaping containers.
100+
Running a shell inside a kubernetes pod allows you to get control of the
101+
kubernetes node and thus of everything that your kubernetes cluster has
102+
access to. Running untrusted code in a container is thus very risky — something
103+
that will affect e.g. CI setups.
104+
105+
## Fixes
106+
107+
A fix to the Linux kernel for Copy.fail was silently merged at the end of March
108+
2026 (for 7.0-rc7) and also been merged to the stable kernel series (6.18.22,
109+
6.12.85, 6.6.137).
110+
It just disables the in-place optimization for `algif_aed`. As of early May,
111+
Linux distributors are currently underway to ship fixed kernels.
112+
Without a fixed kernel, a workaround is to place a file `copyfail.conf` in
113+
`/etc/modprobe.d/` with the contents:
114+
115+
```text
116+
# Temporary workaround for copy.fail CVE-2026-31431
117+
install algif_aead /bin/false
118+
```
119+
120+
The fixes for Dirty Frag are still in development as of May 8. The first fixes
121+
have been merged upstream and released in 7.0.5, 6.18.28, 6.12.87, 6.6.138 but
122+
there is [more to come](https://lwn.net/ml/all/2026050859-ahead-anchovy-05e2@gregkh/).
123+
The responsible disclosure process for Dirty Frag was unfortunately broken,
124+
so the upstream maintainers and the distributors this time did not have time
125+
to carefully prepare and test fixes ahead of the publication of the issue.
126+
So we have to expect that it will take a few days until all Linux distributor
127+
manage to ship tested fixed kernels.
128+
129+
A fully effective workaround is again to prevent loading the affected modules
130+
by placing another file `dirtyfrag.conf` in `/etc/modprobe.d/`:
131+
132+
```text
133+
# Temporary workaround for Dirty Frag CVE-2026-43284, CVE-2026-43500
134+
# This breaks IPsec
135+
install esp4 /bin/false
136+
install esp6 /bin/false
137+
install rxrpc /bin/false
138+
```
139+
140+
Note that these workarounds prevent IPsec from working.
141+
142+
If a system is suspected to already have been exploited, the system owner can
143+
dispose of the page cache by doing `echo 3 > /proc/sys/vm/drop_caches` as root
144+
and unload the affected modules to prevent re-exploitation.
145+
This will discard the modified page cache pages — however an attacker could have
146+
used its gained privileges to install further backdoors etc. into the system, so
147+
it will need to be reinstalled or fully audited to be considered trustable again.
148+
149+
## SCS IaaS Cloud Provider exposure
150+
151+
None of the control-plane / management systems in a normal SCS cloud infrastructure
152+
can be logged in by normal users. The LPE thus can not be exploited. However,
153+
should another exploit be found and used successfully, the LPEs may be used
154+
to escalate privileges further, e.g. breaking out of the containers that run
155+
the OpenStack services or Ceph or some of the management tools and thus remove
156+
one layer of a defense-in-depth concept.
157+
158+
Cloud Providers are advised to install updated kernels to reestablish the defense.
159+
They can apply the module loading prevention measures in the meantime. Providers
160+
are advised to use this with care on the network nodes — if these need to support
161+
IPsec (e.g. for OpenStack's VPNaaS which is part of neutron), the non-loadable
162+
modules may prevent correct operation. Please note that there is no known remote
163+
exploit via IPsec, so a temporary trade-off to live without the defense-in-depth
164+
and not break IPsec (and this way create security and functionality issues or for
165+
customers) may be justified.
166+
167+
Cloud providers often provide VM images for their customers.
168+
To support the customers to keep the security separation in the customer's VMs,
169+
they are advised to watch out for the availability of new distribution images
170+
and provide them short-term via their image service (glance).
171+
172+
## SCS Kubernetes Provider exposure
173+
174+
The default implementation with SCS Cluster Stacks is vulnerable; the current
175+
node images have a kernel that is affected by this weakness. This allows a user
176+
to break out of the containers running in the cluster to take over the node
177+
VM and other containers. With Cluster-API and the SCS Cluster Stacks building
178+
on them, creating, updating and removing Kubernetes clusters has become
179+
a commodity; it is thus normal to create clusters per development team and
180+
not share them. In this scenario, the break out may allow a developer to
181+
take over containers from his team mates which is not a real danger in many
182+
setups. For cluster setups across teams or worse for setups where several
183+
clusters that belong to different entities share a control plane, this becomes
184+
more serious.
185+
186+
Note that the LPE also removes a defense-in-depth mechanism, where a user of
187+
a service running in a k8s cluster exploits a vulnerability to be able to
188+
execute code in the container — the LPEs can then be used to escalate the
189+
privileges further.
190+
191+
As soon as new kernels become available, the node images will be rebuilt and
192+
shipped with the next cluster stack patch releases. For users, the normal
193+
rolling upgrade will then be all that's needed to be secure against this LPE
194+
again.
195+
196+
We will update this advisory as soon as new node images are available.
197+
198+
For highly critical workloads, cluster operators can log in to the nodes
199+
and deploy the mechanisms to prevent loading the above-mentioned modules.
200+
(Again, this will break IPsec.) Note that logging in to nodes in an SCS
201+
Cluster Stack cluster is not possible by default; it requires booting
202+
into a rescue image (if the cluster runs on OpenStack) to inject an ssh
203+
key or to use a tool like kubectl-node-shell with the appropriate
204+
privileges.
205+
206+
## SCS Cloud users
207+
208+
Customers of SCS IaaS clouds are responsible for their own VMs. For VMs
209+
that are exposed, they should use the documented workaround inside their VMs,
210+
online-update and reboot into a fixed kernel or redeploy their VMs based
211+
on a fixed upstream image.
212+
213+
Customers that do their own Kubernetes Container Cluster Management
214+
with e.g. SCS Cluster Stacks are advised to watch out for new node
215+
images and then perform the rolling upgrade. If their use scenario puts
216+
them at increased risk, they are advised to prevent the module loading
217+
in the meantime, as advised above.
218+
219+
## Thanks
220+
221+
The authors would like to thank Taeyang Lee at Xint (who initiated the
222+
research on copy.fail) and Hyunwoo Kim (@v4bel, who discovered Dirty Frag).
223+
They would also like to thank the upstream Linux kernel maintainers and
224+
Linux distributors for their reliable work no handling the issues and
225+
getting fixes out.
226+
227+
## Sovereign Cloud Stack Security Contact
228+
229+
SCS security contact is [security@scs.community](mailto:security@scs.community), as published on
230+
[https://scs.community/.well-known/security.txt](https://scs.community/.well-known/security.txt).
231+
232+
## Version history
233+
234+
- Initial Draft, v0.1, 2026-05-08, 17:15 CEST.

0 commit comments

Comments
 (0)