The suggested mitigation works and rebooting is not necessary, you can just do rmmod esp4; rmmod esp6; rmmod rxrpc in the event they were loaded earlier by something. Confirm with lsmod | grep -E 'esp|rxrpc'. Afterwards, the exploit will fail to run. Tested in a VM running Debian 6.12.57+deb13-amd64.
I’ve noticed rxrpc being present in newish RHELs, while esp4 is present in an older RHEL 8 or old SLES. Both were vulnerable through one module or the other.
cat /boot/config-XX | grep -Ei 'rxrpc|inet_esp|inet6_esp' is useful to tell which modules are in your system, and whether you’re therefore vulnerable. Good: # CONFIG_AF_RXRPC is not set, Bad: CONFIG_INET_ESP=m, CONFIG_INET6_ESP=m
Exploitation leaves the following in /var/log/messages:
May 7 22:19:39 hostname kernel: alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac(sha256-ni),cbc-aes-aesni))
May 7 22:19:39 hostname kernel: alg: No test for echainiv(authencesn(hmac(sha256),cbc(aes))) (echainiv(authencesn(hmac(sha256-ni),cbc-aes-aesni)))
May 7 22:19:47 hostname kernel: process 'su' launched '/bin/sh' with NULL argv: empty string added
Can I see the output of lsmod | grep -E 'esp|rxrpc' and cat /boot/config-XX | grep -Ei 'rxrpc|inet_esp|inet6_esp', as well as your /etc/modprobe.d/dirtyfrag.d?
Using DirtyFrag, Exploit → rmmod rxrpc, /etc/modprobe.d/dirtyfrag.conf with the right lines meant the Exploit could not be used again in my machine.
It looks like the Debian ‘cloud’ kernels do not have the rxrpc module enabled;
$ uname -r
6.12.85+deb13-cloud-amd64
$ grep -Ei ‘rxrpc|inet_esp|inet6_esp’ /boot/config-$( uname -r )
CONFIG_INET_ESP=m
CONFIG_INET_ESP_OFFLOAD=m
CONFIG_INET_ESPINTCP is not set
CONFIG_INET6_ESP=m
CONFIG_INET6_ESP_OFFLOAD=m
CONFIG_INET6_ESPINTCP is not set
CONFIG_AF_RXRPC is not set
While the full kernel does;
$ uname -r
6.12.85+deb13-amd64
$ grep -Ei ‘rxrpc|inet_esp|inet6_esp’ /boot/config-$( uname -r )
CONFIG_INET_ESP=m
CONFIG_INET_ESP_OFFLOAD=m
CONFIG_INET_ESPINTCP is not set
CONFIG_INET6_ESP=m
CONFIG_INET6_ESP_OFFLOAD=m
CONFIG_INET6_ESPINTCP is not set
CONFIG_AF_RXRPC=m
CONFIG_AF_RXRPC_IPV6=y
CONFIG_AF_RXRPC_INJECT_LOSS is not set
CONFIG_AF_RXRPC_INJECT_RX_DELAY is not set
CONFIG_AF_RXRPC_DEBUG is not set
We generally use the ‘cloud’ kernel in all virtual machines, as it is a lot smaller as well. You would still want to enable the mitigations, but, depending on your AppArmor configuration, this may affect how exposed you are, if I am reading the ‘DirtyFail’ description correctly?
Proxmox also has updated kernel packages. For Proxmox 8.x;
$ apt-get changelog proxmox-kernel-6.8 | head -n21
Get:1 https://metadata.cdn.proxmox.com proxmox-kernel-6.8 6.8.12-23 Changelog [39.0 kB]
proxmox-kernel-6.8 (6.8.12-23) bookworm; urgency=medium
cherry-pick fixes for “DirtyFrag” local privilege escalation issue
– Proxmox Support Team support@proxmox.com Fri, 08 May 2026 10:00:51 +0200
proxmox-kernel-6.8 (6.8.12-22) bookworm; urgency=medium
Fix “copy.fail” Local Privilege Escalation / CVE-2026-31431:
An unprivileged local user can write 4 controlled bytes into the page
cache of any readable file on a Linux system, and use that to gain root.
– Proxmox Support Team support@proxmox.com Thu, 30 Apr 2026 09:01:51 +0200
proxmox-kernel-6.8 (6.8.12-21) bookworm; urgency=medium
update submodule to Ubuntu-6.8.0-116.116 and refresh patches.
– Proxmox Support Team support@proxmox.com Sun, 26 Apr 2026 19:55:26 +0200
And Proxmox 9.x;
$ apt-get changelog proxmox-kernel-6.17 | head -n21
Get:1 https://metadata.cdn.proxmox.com proxmox-kernel-6.17 6.17.13-7 Changelog [41.4 kB]
proxmox-kernel-6.17 (6.17.13-7) trixie; urgency=medium
cherry-pick fixes for “DirtyFrag” local privilege escalation issue
– Proxmox Support Team support@proxmox.com Fri, 08 May 2026 11:58:26 +0200
proxmox-kernel-6.17 (6.17.13-6) trixie; urgency=medium
cherry-pick follow-up commits for copy.fail fixes
– Proxmox Support Team support@proxmox.com Thu, 30 Apr 2026 10:48:21 +0200
proxmox-kernel-6.17 (6.17.13-5) trixie; urgency=medium
Fix “copy.fail” Local Privilage Escalation / CVE-2026-31431:
An unprivileged local user can write 4 controlled bytes into the page cache
of any readable file on a Linux system, and use that to gain root.
– Proxmox Support Team support@proxmox.com Thu, 30 Apr 2026 08:30:46 +0200
Somebody check my math here but it seems odd that the RHEL mitigations say to use modprobe? I didn’t think these modules were loaded dynamically for Red Hat like distros. Certainly weren’t for Fedora.
Figured out what I was missing! That kmod loads the module on demand when the kernel demands it during the exploit, despite what lsmod shows me beforehand.
