Skip to content

Commit ebf3a79

Browse files
garloffgarloff
committed
Merge branch 'feat/kernel-lpe-202605' into staging
2 parents 692152f + 8dab1d9 commit ebf3a79

1 file changed

Lines changed: 244 additions & 0 deletions

File tree

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

Lines changed: 244 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,244 @@
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 normally 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 (with kernels from the last 9 years) 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 and doe not require the
74+
namespace creation privileges, but as these bytes are crypted,
75+
the user needs to brute force them in order to achieve a controlled result. This
76+
variant was assigned CVE-2026-43500.
77+
78+
_Exploiting these vulnerabilities requires access to the system and the ability
79+
to execute code there, thus the categorization as Local Privilege Escalation (LPE),
80+
not Remote Code Execution (RCE)._
81+
82+
## Impact
83+
84+
Any system where normal (non-root) users can log in to execute code under their
85+
own control is no longer secure: The users can use the publicly available
86+
exploits to gain root privileges and get access to whatever the (virtual)
87+
machine has access to. This means accessing other user's data as well as secrets
88+
that are stored by the system administrator.
89+
90+
Such systems are less common these days than they were 20 years ago. The reason
91+
is that virtualization has become a commodity, so individual users may use their
92+
own virtual machine rather than having access to a shared (virtual) machine
93+
in many scenarios.
94+
95+
Note that this vulnerability does NOT break the isolation of virtual machines.
96+
VMs remain as securely isolated as they would be without this vulnerability.
97+
These LPEs do NOT establish a virtualization escape.
98+
99+
There is however a common scenario where individual users and workloads
100+
are running inside a container. The LPE also allows for escaping containers.
101+
Running a shell inside a kubernetes pod allows you to get control of the
102+
kubernetes node and thus of everything that your kubernetes cluster has
103+
access to. Running untrusted code in a container is thus very risky — something
104+
that will affect e.g. CI setups.
105+
106+
## Fixes
107+
108+
A fix to the Linux kernel for Copy.fail was silently merged at the end of March
109+
2026 (for 7.0-rc7) and also been merged to the stable kernel series (6.18.22,
110+
6.12.85, 6.6.137).
111+
It just disables the in-place optimization for `algif_aed`. As of early May,
112+
Linux distributors are currently underway to ship fixed kernels.
113+
Without a fixed kernel, a workaround is to place a file `copyfail.conf` in
114+
`/etc/modprobe.d/` with the contents:
115+
116+
```shell
117+
# Temporary workaround for copy.fail CVE-2026-31431
118+
install algif_aead /bin/false
119+
```
120+
121+
The fixes for Dirty Frag are still in development as of May 8. The first fixes
122+
have been merged upstream and released in 7.0.5, 6.18.28, 6.12.87, 6.6.138,
123+
6.1.172, 5.15.206 and 5.10.255 but there is
124+
[more to come for rxrpc](https://lwn.net/ml/all/2026050859-ahead-anchovy-05e2@gregkh/).
125+
The responsible disclosure process for Dirty Frag was unfortunately broken,
126+
so the upstream maintainers and the distributors this time did not have time
127+
to carefully prepare and test fixes ahead of the publication of the issue.
128+
So we have to expect that it will take a few days until all Linux distributor
129+
manage to ship tested fixed kernels.
130+
131+
A fully effective workaround is again to prevent loading the affected modules
132+
by placing another file `dirtyfrag.conf` in `/etc/modprobe.d/`:
133+
134+
```shell
135+
# Temporary workaround for Dirty Frag CVE-2026-43284, CVE-2026-43500
136+
# This breaks IPsec
137+
install esp4 /bin/false
138+
install esp6 /bin/false
139+
install rxrpc /bin/false
140+
```
141+
142+
Note that these workarounds prevent IPsec from working.
143+
144+
If a system is suspected to already have been exploited, the system owner can
145+
dispose of the page cache by doing `echo 3 > /proc/sys/vm/drop_caches` as root
146+
and unload the affected modules to prevent re-exploitation.
147+
This will discard the modified page cache pages — however an attacker could have
148+
used its gained privileges to install further backdoors etc. into the system, so
149+
it will need to be reinstalled or fully audited to be considered trustable again.
150+
151+
## SCS IaaS Cloud Provider exposure
152+
153+
None of the control-plane / management systems in a normal SCS cloud infrastructure
154+
can be logged in by normal users. The LPE thus can not be exploited. However,
155+
should another exploit be found and used successfully, the LPEs may be used
156+
to escalate privileges further, e.g. breaking out of the containers that run
157+
the OpenStack services or Ceph or some of the management tools and thus remove
158+
one layer of a defense-in-depth concept.
159+
160+
Cloud Providers are advised to install updated kernels to reestablish the defense.
161+
They can apply the module loading prevention measures in the meantime. Providers
162+
are advised to use this with care on the network nodes — if these need to support
163+
IPsec (e.g. for OpenStack's VPNaaS which is part of neutron), the non-loadable
164+
modules may prevent correct operation. Please note that there is no known remote
165+
exploit via IPsec, so a temporary trade-off to live without the defense-in-depth
166+
and not break IPsec (and this way create security and functionality issues or for
167+
customers) may be justified.
168+
169+
Cloud providers often provide VM images for their customers.
170+
To support the customers to keep the security separation in the customer's VMs,
171+
they are advised to watch out for the availability of new distribution images
172+
and provide them short-term via their image service (glance).
173+
174+
## SCS Kubernetes Provider exposure
175+
176+
The default implementation with SCS Cluster Stacks is vulnerable; the current
177+
node images have a kernel that is affected by this weakness. This allows a user
178+
to break out of the containers running in the cluster to take over the node
179+
VM and other containers. With Cluster-API and the SCS Cluster Stacks building
180+
on them, creating, updating and removing Kubernetes clusters has become
181+
a commodity; it is thus normal to create clusters per development team and
182+
not share them. In this scenario, the break out may allow a developer to
183+
take over containers from his team mates which is not a real danger in many
184+
setups. For cluster setups across teams or worse for setups where several
185+
clusters that belong to different entities share a control plane, this becomes
186+
more serious.
187+
188+
Note that the LPE also removes a defense-in-depth mechanism, where a user of
189+
a service running in a k8s cluster exploits a vulnerability to be able to
190+
execute code in the container — the LPEs can then be used to escalate the
191+
privileges further.
192+
193+
As soon as new kernels become available, the node images will be rebuilt and
194+
shipped with the next cluster stack patch releases. For users, the normal
195+
rolling upgrade will then be all that's needed to be secure against this LPE
196+
again.
197+
198+
We will update this advisory as soon as new node images are available.
199+
200+
For highly critical workloads, cluster operators can log in to the nodes
201+
and deploy the mechanisms to prevent loading the above-mentioned modules.
202+
(Again, this will break IPsec.) Note that logging in to nodes in an SCS
203+
Cluster Stack cluster is not possible by default; it requires booting
204+
into a rescue image (if the cluster runs on OpenStack) to inject an ssh
205+
key or to use a tool like kubectl-node-shell with the appropriate
206+
privileges.
207+
208+
```bash
209+
for node in $(kubectl get nodes | grep -v '^NAME' | awk '{print $1;}') do;
210+
kubectl node_shell "$node" -- bash -c 'echo -e "# Temporarily disable algif_aead (copy.fail)\ninstall algif_aead /bin/false" > /etc/modprobe.d/disable-aead-copyfail.conf'
211+
kubectl node_shell "$node" -- bash -c 'echo -e "# Temporarily disable esp4, esp6, rxrpc (Dirty Frag)\ninstall esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false" > /etc/modprobe.d/disable-esp46-rxrpc-dirtyfrag.conf'
212+
done
213+
```
214+
215+
## SCS Cloud users
216+
217+
Customers of SCS IaaS clouds are responsible for their own VMs. For VMs
218+
that are exposed, they should use the documented workaround inside their VMs,
219+
online-update and reboot into a fixed kernel or redeploy their VMs based
220+
on a fixed upstream image.
221+
222+
Customers that do their own Kubernetes Container Cluster Management
223+
with e.g. SCS Cluster Stacks are advised to watch out for new node
224+
images and then perform the rolling upgrade. If their use scenario puts
225+
them at increased risk, they are advised to prevent the module loading
226+
in the meantime, as advised above.
227+
228+
## Thanks
229+
230+
The authors would like to thank Taeyang Lee at Xint (who initiated the
231+
research on copy.fail) and Hyunwoo Kim (@v4bel, who discovered Dirty Frag).
232+
They would also like to thank the upstream Linux kernel maintainers and
233+
Linux distributors for their reliable work no handling the issues and
234+
getting fixes out.
235+
236+
## Sovereign Cloud Stack Security Contact
237+
238+
SCS security contact is [security@scs.community](mailto:security@scs.community), as published on
239+
[https://scs.community/.well-known/security.txt](https://scs.community/.well-known/security.txt).
240+
241+
## Version history
242+
243+
- Initial Draft, v0.1, 2026-05-08, 17:15 CEST.
244+
- kubectl node-shell instructions, v0.2, 2026-05-09, 12:45 CEST.

0 commit comments

Comments
 (0)