Dirty Frag: A New Linux Kernel LPE With Public Exploit and No Coordinated Patch

Two page-cache write bugs in the Linux kernel networking stack. Chained, they reach root deterministically — no race condition, no kernel panic on failure, very high success rate.

SEOUL, SOUTH KOREA — A new Linux kernel local privilege escalation vulnerability chain named Dirty Frag was publicly disclosed on May 7, 2026 by security researcher Hyunwoo Kim, affecting most major Linux distributions. Dirty Frag chains two distinct kernel vulnerabilities: CVE-2026-43284 (xfrm-ESP / IPsec Page-Cache Write) and CVE-2026-43500 (RxRPC Page-Cache Write). Together, they enable a local user to gain root privileges on most Linux distributions through deterministic logic bug exploitation.

Tenable, Wiz, AlmaLinux, Sophos, Ubuntu, Red Hat, and CloudLinux have all published advisories. Microsoft Defender is currently seeing limited in-the-wild activity. CISA added Copy Fail (CVE-2026-31431) to its Known Exploited Vulnerabilities catalog with a May 15 patch deadline for federal agencies. The pattern aligns with the Linux-targeted malware tradecraft documented in the QLNX campaign earlier this month.

The two bugs and why their combination is dangerous

CVE-2026-43284 is a vulnerability in the xfrm-ESP component of the Linux kernel IPsec implementation that allows an unprivileged local user to write to the kernel page cache. CVE-2026-43500 is a similar page-cache write vulnerability in the kernel RxRPC subsystem. Both vulnerabilities are individually moderate-severity logic bugs in the kernel networking stack. Chained together as the Dirty Frag exploit chain, they enable an unprivileged local user to deterministically escalate to root on the affected system.

What distinguishes Dirty Frag from most kernel LPE chains is the absence of race conditions and the absence of kernel panic on failure. Most kernel exploitation chains rely on timing-sensitive race conditions that have variable success rates, and on failure paths that can crash the kernel and trigger forensic evidence of the attempted exploitation. Dirty Frag operates via deterministic logic bugs — meaning the exploitation succeeds reliably on every attempt where the prerequisite conditions are met, and failure cases do not trigger a kernel panic that would alert defenders. This combination of high reliability and low forensic footprint makes Dirty Frag operationally attractive to attackers and operationally difficult for defenders.

The disclosure timeline and the embargo break

Kim reported both vulnerabilities privately to Linux kernel maintainers on April 29-30, 2026, following standard coordinated disclosure practice. The expected coordinated disclosure timeline would have given distribution maintainers time to prepare patches and stage releases before public disclosure. Instead, the disclosure was published prematurely on the oss-security mailing list on May 7 after an unrelated third party broke the embargo. Public proof-of-concept exploit code is now available on GitHub at github.com/V4bel/dirtyfrag.

The premature disclosure has consequences both for defenders and the broader coordinated disclosure ecosystem. Distribution maintainers were left scrambling to publish patches and advisories without the full pre-coordination window. Some distributions had patches ready immediately; others published advisories acknowledging the vulnerability but with patches arriving incrementally over the following days. The pattern echoes other recent embargo failures in 2026 and reinforces the operational fragility of multi-party coordinated disclosure for high-impact kernel vulnerabilities.

Affected distributions and the AlmaLinux specifics

Most major Linux distributions are affected by at least one of the two CVEs. Ubuntu (all supported releases), Red Hat Enterprise Linux, CentOS Stream, AlmaLinux 8, 9, and 10, openSUSE Tumbleweed, Fedora, Debian, Arch Linux, Amazon Linux, and CloudLinux have all published advisories. The AlmaLinux specifics are operationally instructive: AlmaLinux 8 is affected only by CVE-2026-43284 because the distribution does not build the rxrpc module at all. AlmaLinux 9 and 10 are affected by CVE-2026-43500 only on systems that have installed the kernel-modules-partner package, which ships rxrpc.ko and lives in the AlmaLinux Devel repository — not part of the official AlmaLinux repositories. If you do not know whether you have kernel-modules-partner installed, you probably do not; rpm -q kernel-modules-partner will confirm.

The ESP vulnerability has been in the kernel since January 2017, when commit cac2661c53f3 moved IPsec ESP receive into an in-place decryption fast path. The RxRPC variant was introduced in June 2023 when the same fast-path pattern was added to rxrpc. The effective lifetime of the chained vulnerability class is approximately nine years on the ESP side and three years on the RxRPC side. Sysdig analysis notes that, given the extended gap between introduction and discovery of these bugs, it is likely both were identified with the assistance of AI tooling.

Why container deployments inherit the risk

Container workloads inherit host kernel exposure. A compromise of any container that can create AF_KEY, XFRM netlink, or AF_RXRPC sockets — the default for unconstrained Docker, containerd, and most Kubernetes pods — escalates to host root. Hardened containerized environments with default seccomp profiles are less likely to be affected because seccomp typically blocks the syscalls needed to trigger the vulnerable code paths. Ubuntu advisory specifically warns that in container deployments executing arbitrary third-party workloads, the vulnerability may additionally facilitate container escape scenarios on top of local privilege escalation on the host. For CI/CD environments running Linux build agents that execute untrusted code — effectively all GitLab, GitHub Actions, and Jenkins self-hosted runner deployments — this is a critical exposure.

The CyberSignal Analysis

Signal 01 — The embargo-break pattern will recur

Dirty Frag is the second Linux kernel LPE in two weeks where coordinated disclosure was disrupted by third-party publication before distribution patches could ship. Pre-script your response for PoC released, no upstream patch yet scenarios. The defensible posture is documented kernel module mitigation procedures, tested in non-production first, that can be rolled to production within hours of next embargo break.

Signal 02 — AI-assisted vulnerability discovery is now reaching nine-year-old kernel code

The ESP page-cache write primitive has been in the kernel since 2017. The fact that two researchers (Theori with Copy Fail, Kim with Dirty Frag) found related bug classes in the same kernel area within two weeks suggests AI tooling is now reliably surfacing dormant logic flaws in mature codebases. Defenders should expect more of this through 2026 and beyond. Pre-script your patching for Linux kernel LPE with public exploit, no patch yet as a recurring scenario, not an exceptional one.

Signal 03 — Container workloads need seccomp profiles by default, not by exception

Container deployments running with default-permissive syscall surfaces are at elevated risk for kernel LPE chains like Dirty Frag. Hardened seccomp profiles that block AF_KEY, XFRM netlink, and AF_RXRPC socket creation are the documented mitigation for this specific class. If your container security posture treats seccomp as optional, this is the moment to reverse that.

What to do this week

1. Inventory your Linux kernel versions across servers, workstations, containers, and CI/CD runners. Map exposure to CVE-2026-43284 and CVE-2026-43500 specifically. Vendor advisories from Ubuntu, Red Hat, AlmaLinux, CloudLinux, and Sophos all list patched kernel versions; use these as your authoritative source.
2. Patch where available. For systems with patches shipped, apply and reboot or use live patching if your distribution supports it. For systems where patches are not yet available, apply mitigation: blacklist the rxrpc module where unused, and restrict AF_KEY socket creation through seccomp or container security profiles.
3. For AlmaLinux specifically: run rpm -q kernel-modules-partner to confirm exposure to the RxRPC variant. If the package is not installed, AlmaLinux 9 and 10 systems are not affected by CVE-2026-43500. Document this exposure status across your AlmaLinux fleet.
4. For container and Kubernetes environments: apply restrictive seccomp profiles that block AF_KEY, XFRM netlink, and AF_RXRPC socket creation. The default Docker seccomp profile already blocks most of these; verify your custom profiles do not allow the syscalls and that pods running with hostNetwork or privileged mode are scoped appropriately.
5. For CI/CD operators (GitLab, GitHub Actions self-hosted, Jenkins runners): the ability to execute arbitrary code on Linux runners that share kernels with build infrastructure is the highest-risk operational scenario. Prioritize patching runner host kernels and apply ephemeral runner architecture where possible so that any successful LPE compromises only the ephemeral runner instance.

Sources