A new Linux kernel privilege escalation issue called Dirty Frag has surfaced only days after the disclosure of Copy Fail, adding another urgent security concern for the Linux ecosystem, especially for administrators managing servers, containers, CI runners, and shared systems.
Above all, Dirty Frag is a local privilege escalation vulnerability and does not enable remote code execution. It allows an unprivileged local user, a compromised container, a CI job, or another process to escalate privileges to root on affected systems.
Security researcher Hyunwoo Kim publicly disclosed Dirty Frag, describing it as a vulnerability class that combines two Linux kernel page-cache write issues. The first affects the IPsec ESP/XFRM path (CVE-2026-43284), and the second affects RxRPC (CVE-2026-43500).
Dirty Frag is similar in impact to Copy Fail but is a distinct vulnerability. While Copy Fail affected the Linux kernel’s crypto subsystem via algif_aead, Dirty Frag involves networking paths related to IPsec ESP/XFRM and RxRPC.
This vulnerability is part of the broader class of page-cache corruption issues, like Dirty Pipe and Copy Fail. The attack exploits kernel paths that process paged buffers, exposing a write primitive in the page cache. Public proof-of-concept code is available, increasing the urgency for prompt action by distributions and administrators.
The highest-risk environments include multi-user servers, shared hosting systems, CI/CD runners, container hosts, Kubernetes nodes, and any system where untrusted users or workloads can execute code.
Moreover, Canonical notes that the vulnerability is also relevant in container deployments running arbitrary third-party workloads, as it may enable container escape in addition to local privilege escalation, though no container-escape proof of concept has been published.
Patch availability varies by distribution. AlmaLinux has released patched kernels for versions 8, 9, and 10 in its testing repository, with production promotion pending. Debian’s tracker lists CVE-2026-43284 as fixed only in Debian sid with Linux kernel 7.0.4-1. As of now, Bullseye, Bookworm, Trixie, and Forky remain vulnerable.
Ubuntu has issued mitigation guidance and lists Ubuntu 14.04 LTS, 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, 24.04 LTS, 25.10, and 26.04 LTS as affected. Canonical’s CVE tracker indicates several Ubuntu kernel packages still require evaluation. The fix will be distributed through Linux kernel image packages when available.
Red Hat confirms that Red Hat Enterprise Linux 8, 9, and 10, as well as OpenShift 4, are affected. The company is expediting fixes and will provide product-specific guidance. The issue remains ongoing in its advisory. openSUSE and SUSE are also tracking Dirty Frag with the then-current Leap 16.0 and Tumbleweed kernels affected.
The recommended fix is to apply a patched kernel and reboot. Temporary mitigation from vendors involves disabling vulnerable modules when not required, including blacklisting esp4, esp6, and rxrpc. Some guidance also recommends blacklisting related IPsec compression modules such as ipcomp4 and ipcomp6.
However, this workaround is not suitable for all systems. Disabling these modules may disrupt machines using IPsec VPNs, strongSwan, Libreswan, AFS, RxRPC, or related networking features. Canonical warns that the mitigation affects IPsec ESP and RxRPC functionality, and that disabling only one component leaves the other exploitable.
Administrators should update the kernel as soon as patched packages are available, reboot into the fixed kernel, and apply temporary module blacklisting only if the affected functionality is not needed. In container-heavy and multi-user environments, treat Dirty Frag as a high-priority Linux kernel security issue.
As far as I can see all of the vulnerability descriptions describe LOCAL escalation. That means someone has to be ON your machine to implement the exploit AT your machine. That is more likely on shared or multi-user machines, and FAR less likely on a single person laptop or chromebook. I have been promised the patches or work-around within 24 hours, and one work-around is already in my hands. It seem to me the threat is WAY overblown!
Does this effect wifi routers since they run on linux. My routers seem to only get updates once or twice a year and next year on march 1st all routers are banned from receiving updates unless they have a plan to start making them in america.