Dirty Frag (CVE-2026-43284, CVE-2026-43500), Second Linux Kernel LPE in a Week, Bypasses the Copy Fail Mitigation

One week after Copy Fail, security researcher Hyunwoo Kim (@v4bel) publicly disclosed "Dirty Frag," a second Linux kernel local privilege-escalation chain in the same broad area (in-place decryption of paged socket buffers), tracked as CVE-2026-43284 for the IPsec ESP half (esp4, esp6) and CVE-2026-43500 for the rxrpc half. Per Kim's oss-security disclosure on May 7, the responsible-disclosure embargo was broken by an unrelated third party before distributions could coordinate a patch, so Kim released the full write-up and PoC at the maintainers' request. A working public exploit gives any unprivileged local user root in a single command on affected systems. A second public exploit circulating as "Copy Fail 2: Electric Boogaloo" targets the same vulnerability under a different name; both reach root through the same code paths and are blocked by the same fix. Critically, the Copy Fail mitigation (blacklisting algif_aead) does not block Dirty Frag.

Framing note: this bulletin is the direct successor to the Copy Fail (CVE-2026-31431) bulletin and assumes the same audience: operators of multi-tenant Linux hosts, container build farms, Kubernetes nodes, self-hosted CI runners, and any system where untrusted users can get a shell. The primary source is Kim's oss-security post and write-up; AlmaLinux is the most authoritative downstream for technical detail and the only mainstream distribution shipping patched kernels at the time of publication. Other vendor advisories are referenced where available. There is genuine ambiguity in public reporting about whether Dirty Frag is fully unprivileged on every distribution; that is addressed in the "Am I affected" section rather than papered over.

Priorities, by environment

The triage axis is the same as for Copy Fail: who has shell access on the host, and what does that host's kernel boundary protect. The new wrinkle is that prior Copy Fail mitigations do not transfer; every host you previously hardened needs to be re-evaluated against this distinct primitive.

Prioritization framing is this bulletin's own; severity tier from Hyunwoo Kim's disclosure characterizing the bug class as a deterministic logic flaw with very high exploitation success rate. CISA-ADP and Canonical rate CVE-2026-43284 as 7.8 HIGH; Red Hat rates it as Important; NVD's own score is pending publication for both CVEs.

Am I affected?

Three checks, in order. The first two are quick; the third determines whether the unprivileged-to-root path is open on your specific configuration.

1. Is your kernel in the vulnerable window?

Effectively every mainstream distribution kernel released between 2017 and the upstream fix landing earlier this week is vulnerable on the ESP path. The rxrpc path was introduced in mid-2023. Get your running kernel version:

uname -r

Compare against the patched-version table above for your distribution. If you are on AlmaLinux, the patched builds are in the testing repo today; the post-update version is what you compare against. If you are on a distribution that has not yet shipped a patch, you are vulnerable.

2. Are the affected modules loaded or auto-loadable?

lsmod | grep -E 'esp4|esp6|rxrpc'
modinfo esp4 esp6 rxrpc 2>/dev/null | grep -E '^(filename|name):'

The first command shows what is currently loaded; the second confirms the modules are present on disk and would be auto-loaded on demand. esp4 and esp6 ship in the standard kernel package on essentially every mainstream distribution; if either is present and loadable, the ESP path is in scope. rxrpc availability is narrower and varies by distribution and package set: AlmaLinux 8 does not ship it at all (so AL8 is only affected by CVE-2026-43284); AlmaLinux 9 and 10 ship it only via the kernel-modules-partner subpackage from the Devel repo, which should not be on production systems and can be removed with dnf remove kernel-modules-partner; CloudLinux notes rxrpc is not present on typical web-hosting servers. Wherever rxrpc is present and loadable, however, treat it as exploitable: it is the module that bypasses the AppArmor namespace restriction on Ubuntu and is the path Dirty Frag uses to claim "universal" coverage.

3. Can an unprivileged user actually trigger it on your host?

This is the nuance Wiz called out and that matters operationally. The two halves of Dirty Frag have different preconditions:

The xfrm-ESP path (CVE-2026-43284) requires the unprivileged user to create a network namespace. On stock Ubuntu, this is blocked by AppArmor's userns restriction by default. On RHEL family, Fedora, openSUSE, AlmaLinux, and most other distributions, unprivileged user namespaces are enabled by default and the ESP path is reachable. Inside containers, whether namespace creation is permitted depends on the runtime's seccomp / capability profile; a container with CAP_NET_ADMIN or with unrestricted user-namespace creation hits this path.

The rxrpc path (CVE-2026-43500) does not require namespace privileges and is the path Dirty Frag uses to bypass Ubuntu's AppArmor restriction. However, rxrpc.ko is the AF_RXRPC transport used almost exclusively by AFS clients and is not present in the default module set on most distributions. Where it is present and loadable, the unprivileged path is open.

The combination matters for triage but should not be read as reassurance. Canonical confirms all listed Ubuntu releases are impacted and that the published exploit executes on non-container deployments, while warning specifically about container-escape scenarios where arbitrary third-party workloads run. Some distro hardening (Ubuntu's AppArmor userns restriction, RHEL's optional user.max_user_namespaces=0 sysctl) blocks the ESP-only trigger path, but the rxrpc path bypasses those mitigations wherever the module is loadable. Do not treat stock Ubuntu as safe; follow Canonical's mitigation or update guidance, and apply the module blacklist on any multi-tenant host regardless of distribution.

Response, in priority order

1. If you are on AlmaLinux, install the testing-repo kernel today. AlmaLinux's core team backported the upstream ESP fix and shipped patched kernels for every supported branch within a day of the fix landing, ahead of the corresponding RHEL update. Per AlmaLinux's instructions:

   sudo dnf install -y almalinux-release-testing
   sudo dnf update 'kernel*' --enablerepo=almalinux-testing
   sudo reboot
   uname -r   # confirm patched build per the version matrix above
   sudo dnf config-manager --disable almalinux-testing   # if production

   AlmaLinux Kitten 10 ships the patch directly to the regular repo; just dnf update 'kernel*' and reboot.
2. If you are on any other distribution, blacklist the three modules now while waiting for the patched kernel. This is the workaround Kim, AlmaLinux, CloudLinux, and Phoronix all converge on. It is safe to apply on any host that does not terminate IPsec ESP tunnels (strongSwan, Libreswan) or run AFS / rxrpc clients. The single command:

   sudo 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"

   This writes a modprobe config that prevents auto-load and unloads the modules if currently resident. To revert, remove /etc/modprobe.d/dirtyfrag.conf and reload as needed.
3. Do not skip this just because you mitigated Copy Fail last week. The algif_aead blacklist that defended against Copy Fail does not affect Dirty Frag. The two vulnerabilities share a bug class but live in entirely different kernel subsystems (AF_ALG vs xfrm/rxrpc). On hosts where you applied the Copy Fail mitigation, audit for the new modules and apply the Dirty Frag blacklist as a separate step.
4. If you must keep IPsec functional on a RHEL-family host, consider the namespace-disable mitigation as a partial measure. Red Hat's RHSB-2026-003 documents an alternative for environments that cannot blacklist esp4 / esp6 because they terminate IPsec tunnels: disabling unprivileged user namespaces blocks the ESP variant by removing the namespace creation the exploit chain requires.

   echo "user.max_user_namespaces=0" > /etc/sysctl.d/dirtyfrag.conf
   sysctl --system

   Important caveats, per Red Hat: this is partial coverage, not a full mitigation. On RHEL 9 and 10 the rxrpc variant (CVE-2026-43500) remains exploitable unless rxrpc is also blacklisted. Disabling unprivileged user namespaces also breaks rootless containers, sandboxed browsers, and Flatpak. Treat this as the IPsec-heavy-environment workaround, not as equivalent to the full module blacklist.
5. Identify legitimate IPsec and AFS users before rolling the blacklist at scale. Hosts that terminate IPsec tunnels via the kernel data path (most strongSwan and Libreswan deployments use kernel ESP, not userspace) will lose tunnel functionality if you blacklist esp4 / esp6. AFS clients (largely academic and a handful of legacy enterprise sites) need rxrpc. For these workloads, prioritize patching the kernel over the blacklist; the kernel patch fixes the underlying flaw without disabling the modules. On OpenShift, Red Hat confirms the module-blacklist mitigation does not require node reboots (kb 7142250); apply it cluster-wide while waiting for z-stream patched kernels.
6. Drop the page cache after applying the mitigation. The Dirty Frag exploit corrupts pages of sensitive files (commonly /etc/passwd or /usr/bin/su) in the page cache; the corruption survives in memory until those pages are evicted. Per AlmaLinux's guidance, after blacklisting or patching, evict cached pages so the next read comes from disk:

   sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

   This is safe on a live system; it only frees clean cache and dentry/inode entries. It will not undo a successful prior root escalation (the resulting root shell or persistence mechanism is not in the page cache), but it prevents the in-memory corruption from being read again.
7. Hunt for prior exploitation on hosts that were exposed. The exploit does not leave a clean process-tree signature; the immediate artifact is a successful su or other setuid invocation by an unprivileged user with no preceding interactive password prompt. Audit your auth logs for su / sudo sessions where the elevation cannot be explained by interactive auth, and your system journals for unprivileged users invoking setuid binaries in unusual contexts. For active-exploit detection, the relevant primitives are XFRM/netlink configuration activity from unprivileged contexts, unexpected creation of network namespaces by non-root users, AF_RXRPC socket use on hosts that do not run AFS, and unexplained compilation or execution of unfamiliar binaries in /tmp, /dev/shm, or user home directories around the same window. auditd rules on socket(AF_RXRPC) and on unshare(CLONE_NEWUSER|CLONE_NEWNET) by non-root callers catch the live exploit but not post-exploit persistence.
8. Reboot to the patched kernel as soon as it is available for your distribution. This is a kernel patch, not a livepatch by default. CloudLinux is shipping a KernelCare livepatch; if you use a livepatch service, follow vendor guidance for activation. Verify post-reboot with uname -r against your distribution's published patched version. The blacklist mitigation can be kept in place after patching if the host does not need the modules; defense in depth is fine.

The bigger picture: this bug class is not finished

Dirty Pipe (2022), Copy Fail (April 2026), and now Dirty Frag (May 2026) are all instances of the same underlying pattern: the kernel performs an in-place operation over a paged buffer that is not privately owned by the kernel, leaving an unprivileged userspace reference to a page the kernel then writes through. Each instance lives in a different subsystem (pipe buffers, AF_ALG AEAD path, xfrm ESP, rxrpc), but the primitive and the exploitation pattern are the same: turn a 4-byte controlled write in the page cache into a setuid-binary hijack. This is the third such bug in four years and the second in a week. Operators of multi-tenant Linux should expect at least one more instance of this class to surface before the upstream allocator and zero-copy paths are restructured to make the pattern impossible. In the meantime, the standing posture is: assume any kernel operating on splice / sendfile / MSG_SPLICE_PAGES paged buffers is a potential variant, treat shell access on a multi-tenant Linux host as effectively root-equivalent until proven otherwise, and patch kernel CVEs in this area on the same operational tempo as edge-appliance pre-auth RCEs.