A new Linux kernel vulnerability class dubbed “Dirty Frag”[1] has been publicly disclosed before patches were widely available, along with proof-of-concept (PoC) exploit code. This issue can allow an unprivileged local user to obtain root (full) privileges on many major Linux distributions. Immediate attention is required for environments where untrusted code can run locally (e.g., shared servers, CI runners, container hosts, bastion/jump servers).
Description
Dirty Frag is a universal local privilege escalation (LPE) technique that can achieve root privileges by chaining two kernel issues: xfrm-ESP Page-Cache Write and RxRPC Page-Cache Write. The weaknesses sit in the in-place decryption “fast paths” of the esp4, esp6, and rxrpc kernel modules.Because the coordinated disclosure embargo was broken, the researcher published technical details and the PoC while many distributions were still preparing fixes. At the time of writing there is no widely distributed patch baseline and no consistently assign ed CVE across vendors (CVE-2026-43284 and CE-2026-43500 are mentioned by CloudLinux[2] and SUSE[3]).
Impact
We estimate the impact of this vulnerability as High. An attacker who can execute code locally (including via an initial foothold such as a compromised service account, vulnerable web application, or misconfigured container workload) may be able to:
- Escalate from an unprivileged user to root (full system control).
- Modify protected system files in memory (page cache), enabling persistent privilege escalation behaviour until cache is cleared or the system is rebooted.
- Disable security controls, plant backdoors, access sensitive data, and tamper with workloads running on the host.
Risk
The risk level of this vulnerability is High, because:
- Public PoC exploit code is available.[4]
- The disclosure occurred before coordinated patch rollouts, leaving a window where mitigations may be the only immediate option.
- The Linux kernel is widely deployed across server, cloud, and platform environments, so the exposure footprint can be large.
Mitigation
- Apply vendor patches as soon as they become available: Monitor your distribution/vendor security advisories and update the kernel promptly when fixes are released. Some vendors have indicated testing builds and/or livepatch efforts are underway.
- Immediate workaround: blacklist and unload vulnerable modules (where feasible): A widely recommended workaround is to prevent loading and unload the affected modules (esp4, esp6, rxrpc) if they are not required in your environment:
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"
Note that disabling esp4/esp6 can break IPsec VPN/tunneling on systems that rely on kernel ESP transforms. - Clear page cache (recommended after applying mitigation): Because the exploit targets page cache, multiple advisories recommend rebooting after mitigations, especially if you suspect prior exposure.
What should you do?
- Identify Linux systems: where untrusted users/workloads can execute locally (shared servers, CI runners, container hosts, bastions)
- Check whether the modules are present/loaded:
lsmod | egrep '^(esp4|esp6|rxrpc)\b' - If your operational requirements allow it, apply the workaround (blacklist/unload modules) on priority systems first.
- Plan for kernel patching: as soon as your distribution releases fixes; schedule reboots where needed.
- If you suspect compromise or have high exposure: Review local auth and privilege escalation traces (sudo logs, PAM/auth logs, unusual local users).
What will Northwave do?
Vulnerability Management customers will be informed in case vulnerable systems are detected in their infrastructure. We will continue to monitor developments related to this attack. If new critical information arises, we will contact you. If you would like additional information, please feel free to call us or send an email.
E-mail: soc@northwave-cybersecurity.com
Do you have an incident right now? Call our Incident Response Team: 00800 1744 0000
Disclaimer applies, see below.
Sources
[1]: https://www.phoronix.com/news/Dirty-Frag-Linux
[2]: https://blog.cloudlinux.com/dirty-frag-mitigation-and-kernel-update
[3]: https://www.suse.com/c/addressing-copy-fail2-aka-dirtyfrag-in-suse-virtualization/
[4]: https://github.com/V4bel/dirtyfrag