SlowMist alert: SlowMist alert—High-risk privilege escalation vulnerability in Linux—disable three modules as an emergency mitigation

Mysterious Fog’s Chief Information Security Officer 23pds disclosed on May 8 that Linux systems have a serious privilege escalation vulnerability named Dirty Frag. Complete details and exploit code have been made public: any local low-privilege user can directly obtain root administrator privileges on the affected system without needing specific system conditions. The emergency mitigation is to disable three modules: esp4, esp6, and rxrpc.

Why is Dirty Frag so dangerous: logic flaw, high success rate, no patch

Dirty Frag is a deterministic logic vulnerability, not an unstable attack that depends on race conditions, which makes it extremely likely to succeed and reliably reproducible. An attacker only needs to run a small program to immediately obtain root privileges on the target system. The entire process does not cause the kernel to crash, making it very hard to detect by routine monitoring.

The vulnerability was submitted by security researchers to the Linux kernel team on April 30, but before the patching work was completed, a “seemingly unrelated third party” leaked the detailed information and exploit code early, forcing the security ban to be lifted. The security community generally believes this means malicious attackers may already be actively exploiting the vulnerability.

From the technical mechanism, Dirty Frag is similar to the Copy Fail vulnerability that has caused widespread harm in the Linux server ecosystem today. Both implement the attack by inserting a page-cache descriptor into a zero-copy operation. The underlying vulnerability, “xfrm-ESP Page-Cache Write,” was introduced by a kernel commit from 2017, cac2661c53f3. Since Ubuntu’s AppArmor fixed this vulnerability, the PoC links a second vulnerability, “RxRPC Page-Cache Write” (commit 2dc334f1a63a), ensuring the attack remains effective on Ubuntu systems as well.

Affected scope: confirmed list of major Linux distributions

Confirmed affected Linux distributions (partial):

· Ubuntu 24 and Ubuntu 26 (including AppArmor, bypassing via the second vulnerability)

· Arch Linux (updated versions also confirmed to be affected)

· RHEL (Red Hat Enterprise Linux)

· OpenSUSE

· CentOS Stream

· Fedora

· AlmaLinux

· CachyOS (kernel version 7.0.3-1-cachyos confirmed to trigger)

· WSL2 (Windows Subsystem for Linux) also confirmed to be affected

Emergency mitigations: specific commands to disable the three modules

Before official patches are released, the most effective mitigation is to disable the three modules: esp4, esp6, and rxrpc. These three modules are all related to IPSec network functionality. Unless the server itself is an IPSec client or server, disabling them has almost no impact on normal business operations.

Run the following command to disable the modules: sh -c “printf ‘install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n’ > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true”

After completing the steps, closely monitor security announcements from each Linux distribution, and deploy system updates immediately after the official patches are released.

FAQ

Does Dirty Frag have an official patch yet?

As of now, no official patches have been released, and no fix commit has been seen in the Linux mainline kernel. This is because the security ban was broken before the patching work was completed, leading to the vulnerability details being published while remediation was still unfinished. System administrators should closely track security announcements from Linux distributions and deploy immediately after patches are released.

Will disabling esp4, esp6, and rxrpc modules affect normal server operations?

These three modules are mainly related to IPSec protocols. Unless the server itself is an IPSec client or server (i.e., used for encrypted communication at the network layer), disabling these modules will almost never affect common business workloads such as Web services, databases, and encryption nodes. This is currently the safest emergency mitigation with minimal impact.

Why was this vulnerability disclosed without a patch before it was fixed?

Industry practice is “responsible disclosure”—after security researchers submit a vulnerability to the vendor, they typically wait for the patch to be completed before publishing details. This vulnerability was submitted on April 30, but a “seemingly unrelated third party” leaked the detailed information early, breaking the embargo. Security researchers speculate that a malicious attacker may have already been actively exploiting the vulnerability, which is also the triggering reason for ultimately lifting the embargo.