CVE-2026-31431

Overview

CVE-2026-31431, nicknamed "Copy Fail," is a local privilege escalation vulnerability in the Linux kernel's algif_aead module — the AEAD (Authenticated Encryption with Associated Data) socket interface of the kernel's userspace crypto API (AF_ALG). Discovered by Theori researcher Taeyang Lee using the AI-assisted Xint Code scanning tool, the flaw lets any unprivileged local user gain root access within seconds. A working 732-byte Python proof-of-concept exploit runs unmodified against Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, and SUSE 16 — every mainstream Linux distribution built since 2017 is affected.

The vulnerability was introduced by a 2017 in-place processing optimization (commit 72548b093ee3) and fixed by reverting that change (commit a664bf3d603d). The name "Copy Fail" reflects the flaw's essence: a kernel copy operation that should not modify its source ends up writing into the page cache of privileged binaries.

What is the Linux Kernel?

The Linux kernel is the foundational software layer between hardware and user-space programs, running in every major Linux distribution — enterprise servers (RHEL, Ubuntu, SUSE), cloud instances on AWS, GCP, and Azure, Android smartphones, IoT devices, and container runtimes. As the most privileged code on any Linux system, a privilege escalation flaw in the kernel allows any local user — a restricted shell account, a compromised web application, or code running in a container — to obtain complete control of the host. Because every major distribution ships affected kernel builds, "Copy Fail" has an unusually broad blast radius compared to application-level CVEs.

Affected Versions

The vulnerability was introduced in July 2017 via commit 72548b093ee3. Every Linux kernel from 4.14 onward through pre-7.0 is affected.

Affected distributions (at time of public disclosure on April 29, 2026): Ubuntu 24.04 LTS, Amazon Linux 2 and 2023, RHEL 10.1, SUSE 16, AlmaLinux, Rocky Linux, Debian, and derivatives. CERT-EU noted that as of the disclosure date, no major distribution had yet shipped a fixed kernel package.

Technical Details

Root Cause: Page Cache Pages in the Writable Scatterlist

The AF_ALG interface exposes kernel cryptographic functions to userspace via sockets. In 2017, commit 72548b093ee3 introduced an in-place processing optimization for AEAD operations in algif_aead: rather than always copying data to a new buffer, it allowed page-cache pages to be placed directly into a writable destination scatterlist.

The authencesn cryptographic template, when operating in AEAD mode, writes a small "scratch" block to a fixed offset in the destination scatterlist. The exact vulnerable line in the kernel source is:

scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 1);

This writes 4 bytes past the legitimate output boundary — a deterministic, controlled write whose target offset is tunable via assoclen and splice parameters, and whose value is controlled via the AAD bytes 4–7 of the crafted AEAD request. When the destination scatterlist holds a page-cache page (a kernel-managed in-memory cache of a file on disk), that scratch write lands directly in memory backing a readable file. An attacker can steer this write at the page-cache copy of any setuid binary — such as /usr/bin/su — by chaining AF_ALG socket operations with splice().

Exploitation Mechanism

The exploit:

1. Opens an AF_ALG AEAD socket and sets up an authencesn algorithm session
2. Uses splice() to map the page-cache pages of a target setuid binary (e.g., /usr/bin/su) into the socket's scatterlist
3. Triggers the AEAD operation, causing authencesn's scratch write to corrupt exactly 4 bytes within that page-cache page
4. Carefully chosen target bytes overwrite instruction bytes in the setuid binary's in-memory representation, redirecting execution to attacker-controlled shellcode
5. Executes the now-modified in-memory copy of /usr/bin/su to obtain a root shell

Crucially, the on-disk file is never modified. The corruption exists only in the kernel's page cache. Standard disk-based forensics (file integrity checkers, checksums) will not detect it. The modification disappears on reboot or if the kernel evicts the page under memory pressure.

The published exploit requires only standard Linux syscalls (socket, setsockopt, splice, sendmsg, recvmsg) and the authencesn algorithm which is available in default kernel configurations. No race conditions, no timing windows, no version-specific payloads are required.

Attack Characteristics

Comparison to Prior Linux Kernel LPEs

Copy Fail draws direct comparisons to two previous high-profile Linux kernel privilege escalation flaws:

Copy Fail is considered more reliable than Dirty Cow (race condition) and similarly impactful to Dirty Pipe, but affecting a broader kernel version range.

Discovery

On March 23, 2026, Taeyang Lee of Theori reported the vulnerability to the Linux kernel security team. The flaw was discovered using Theori's AI-assisted security analysis tool, Xint Code, which identified the dangerous in-place semantics introduced by commit 72548b093ee3 in 2017 — a near-decade-old optimization that had gone undetected through standard review.

Theori noted that the same research effort uncovered additional kernel security flaws, including at least one other privilege escalation issue, which remained under coordinated disclosure at the time of Copy Fail's public release.

Exploitation Context

A working public exploit was released on the same day as public disclosure (April 29, 2026), giving defenders essentially no window before reliable exploitation became possible by any threat actor.

• PoC: theori-io/copy-fail-CVE-2026-31431 — 732-byte Python script, no dependencies
• Tested platforms: Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, SUSE 16
• Container escape: Theori's Part 2 research covers exploitation from within containers
• Detection rule (Sysdig Falco): The Sysdig Threat Research Team published a Falco detection rule targeting the AF_ALG + splice() + setuid binary chain

CISA added Copy Fail to the KEV catalog on May 1, 2026 — two days after disclosure — confirming confirmed evidence of in-the-wild exploitation against federal or critical infrastructure targets.

A related pair of vulnerabilities — Dirty Frag (CVE-2026-43284 / CVE-2026-43500) — in the same page-cache write class was disclosed one week later by researcher Hyunwoo Kim, with limited in-the-wild exploitation confirmed as of May 8, 2026. See the Dirty Frag section below for details and interim mitigations.

Method of Detection

Check the Running Kernel Version

uname -r

Compare the output against the fixed versions in the Affected Versions table. Any kernel from 4.14 through the pre-fix versions is vulnerable. The algif_aead module loads on demand, so an unpatched kernel is at risk even if the module is not currently active.

Check Whether the Kernel Was Built With AEAD Support

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

Check Whether the Module Is Currently Loaded

Only applicable when CONFIG_CRYPTO_USER_API_AEAD=m (built-in modules do not appear in lsmod):

lsmod | grep algif_aead

Any output means the module is currently loaded and the attack surface is live. No output means it is not active at this moment but can still be demand-loaded unless explicitly blacklisted (see Workaround below).

Runtime Behavioral Detection (Falco)

The Sysdig Threat Research Team published a Falco rule targeting the exploit's syscall chain: socket(AF_ALG, SOCK_SEQPACKET) followed by splice() calls against a setuid binary. The rule is documented in Sysdig's Copy Fail analysis. Deploy it on any host where the module cannot be immediately blacklisted.

Critical limitation: Copy Fail corrupts only the kernel page cache — never the on-disk binary. File integrity monitoring tools (AIDE, Tripwire, auditd file watches, IMA/EVM) will not detect an active or completed exploit. The corrupted page-cache entry disappears on reboot or under memory pressure, leaving no persistent forensic trace on disk.

Reliable Detection: What Works and What Doesn't

Why Most Approaches Fail

Copy Fail's defining forensic property is that no file on disk is ever modified. The exploit writes into the kernel page cache — a transient in-memory representation — and that write disappears on the next reboot or when the kernel reclaims the page under memory pressure. This eliminates entire categories of tooling:

The only reliable detection window is while the exploit is running — observing the kernel syscall sequence in real time.

eBPF-Based Detection

eBPF programs attached to syscall entry points provide the lowest-latency, highest-fidelity detection primitive. Tools like Cilium Tetragon, bpftrace, and the Falco eBPF driver all operate on the same underlying event stream.

The exploit's syscall fingerprint is highly distinctive:

1. socket(AF_ALG=38, SOCK_SEQPACKET, 0) — opens an AF_ALG socket (legitimate software rarely does this outside of libkcapi and HSM middleware)
2. bind() with struct sockaddr_alg — sets salg_type="aead" and a specific algorithm name such as authencesn(hmac(sha512),cbc(aes))
3. accept() — creates the AEAD operation file descriptor
4. splice() from a setuid binary's open file descriptor into the ALG socket — the critical indicator

The combination of step 1 and step 4 targeting a setuid binary is unique to this exploit class in practice. Legitimate use of splice() feeding page-cache pages into an AF_ALG AEAD socket is rare enough that a low false-positive alerting rule is feasible on most server workloads.

bpftrace — detect any AF_ALG socket creation:

bpftrace -e 'tracepoint:syscalls:sys_enter_socket /args->family == 38/ {
  printf("AF_ALG socket: pid=%d comm=%s\n", pid, comm);
}'

Cilium Tetragon TracingPolicy — kill or alert on AF_ALG socket creation:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: copy-fail-af-alg-detect
spec:
  kprobes:
    - call: "__sys_socket"
      syscall: true
      args:
        - index: 0
          type: "int"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Equal"
              values:
                - "38"      # AF_ALG
          matchActions:
            - action: Post  # change to Sigkill to block outright

Falco Syscall Rules

A production-grade Falco ruleset for Copy Fail:

- rule: Copy Fail — AF_ALG AEAD Socket Opened (CVE-2026-31431)
  desc: >
    Detects AF_ALG socket creation, the first step of the Copy Fail LPE
    exploit chain. Legitimate AF_ALG AEAD users are rare (libkcapi, some
    HSM middleware); this should alert on virtually all server workloads.
  condition: >
    evt.type = socket and
    evt.arg.domain = AF_ALG and
    not proc.name in (libkcapi_test, afalg_test)
  output: >
    AF_ALG socket opened — possible Copy Fail exploit attempt
    (user=%user.name pid=%proc.pid command=%proc.cmdline
    container=%container.name image=%container.image.repository)
  priority: WARNING
  tags: [cve_2026_31431, host, container, privilege_escalation]

- rule: Page Cache LPE — splice() Targeting Setuid Binary
  desc: >
    Detects splice() calls where the source file descriptor is a setuid
    binary. This is the core syscall primitive of the Copy Fail page-cache
    write exploit chain.
  condition: >
    evt.type = splice and
    fd.filename in (/usr/bin/su, /usr/bin/sudo, /usr/bin/newgrp,
                    /usr/bin/passwd, /usr/bin/chsh, /usr/bin/pkexec,
                    /usr/bin/mount, /usr/bin/umount)
  output: >
    splice() targeting setuid binary — possible page-cache LPE exploit
    (user=%user.name pid=%proc.pid fd=%fd.name
    container=%container.name image=%container.image.repository)
  priority: CRITICAL
  tags: [cve_2026_31431, host, container, privilege_escalation]

Add both rules to falco_rules.local.yaml — they are not included in Falco's default ruleset. The AF_ALG rule is specific to Copy Fail; the splice() + setuid rule catches the broader page-cache write primitive and applies to related vulnerabilities in the same class (see Dirty Frag section below).

Limitation of Falco rules: Falco fires on syscall events as they occur. If Falco is not running at the moment of exploitation (e.g., the daemon is stopped or the eBPF probe failed to load), the event is missed. Falco does not retroactively detect a completed exploit — the page-cache corruption leaves no hook for a post-hoc rule.

Container Seccomp Profiles

Seccomp operates as a syscall filter in kernel space — it blocks the offending syscall before it can take effect, making it both a prevention and a detection control. A seccomp violation generates an audit event visible via dmesg and auditd.

Minimum effective block — deny socket() with domain == AF_ALG (38):

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "errnoRet": 1,
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ"
        }
      ]
    }
  ]
}

Save this as seccomp-no-af-alg.json and apply it:

# Docker
docker run --security-opt seccomp=seccomp-no-af-alg.json <image>

# Kubernetes — set in pod spec securityContext
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: seccomp-no-af-alg.json

Detection via auditd (host or privileged container):

By default SCMP_ACT_ERRNO silently returns an error with no log entry. For audit visibility, configure auditd to capture all AF_ALG socket calls independently of seccomp:

auditctl -a always,exit -F arch=b64 -S socket -F a0=38 -k af_alg_socket

This captures every socket() call where argument 0 is 38 (AF_ALG) and tags the event af_alg_socket in the audit log. False-positive rate is very low on standard server workloads — the only common legitimate users are libkcapi-linked applications and some HSM/PKCS#11 middleware.

Alternatively, use SCMP_ACT_LOG in the seccomp profile to log-but-allow, which writes to dmesg without blocking; useful during a detection-only rollout before moving to SCMP_ACT_ERRNO.

Blocking AF_ALG socket creation prevents Copy Fail but does not cover related vulnerabilities in the same page-cache write class that use different kernel entry points. See the Dirty Frag section below for module-level container mitigations applicable to those CVEs.

SentinelOne (Singularity)

SentinelOne has CVE-2026-31431 in its vulnerability database — Singularity Vulnerability Management will flag unpatched Linux endpoints and Kubernetes nodes based on the running kernel version.

What works:

What doesn't work:

The kernel page-cache write happens entirely inside the kernel. No userspace EDR agent — SentinelOne or otherwise — can intercept it. SentinelOne can kill the resulting root process after the fact, but the corrupted page-cache entry persists until reboot. A second exploitation attempt in the same boot session may succeed before the kill response fires.

The behavioral UID-transition detection fires on the outcome (root shell spawned from unprivileged process), not on the mechanism (AF_ALG + splice chain). Out-of-the-box detection does not specifically identify Copy Fail as opposed to any other LPE. Mechanism-level detection requires a manually authored STAR rule against Deep Visibility.

Recommended configuration:

1. Verify Singularity Vulnerability Management is scanning Linux workloads — confirm CVE-2026-31431 appears in the unpatched asset list.
2. Ensure the Linux agent is running in Protect mode (not Detect-only) so automated kill responses can execute.
3. Author a Deep Visibility STAR rule targeting EventType = "IP Connect" or process events where SrcProcName shows Python or shell interpreter and a subsequent TgtFileIsExecutable = true root-owned process is created from a non-root parent — this covers the behavioral signature without requiring syscall-level AF_ALG visibility.

Remediation

Workaround

Prerequisite: First confirm that CONFIG_CRYPTO_USER_API_AEAD=m (module form) via the kernel config check above. If the result is =y (built-in), the module is compiled directly into the kernel and cannot be blacklisted — patching is the only option.

If a patched kernel package is not yet available from your distribution, apply both commands below — they serve different purposes and both are required:

# Prevent the module from loading on next boot and on any future modprobe call
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf

# Unload the module immediately if it is currently in memory
rmmod algif_aead 2>/dev/null

The first command writes a persistent blacklist entry — it survives reboots but does not affect a module that is already loaded. The second command evicts the module from the running kernel right now; the 2>/dev/null suppresses the harmless error if the module was not loaded to begin with.

Compatibility Impact of Blocking algif_aead

algif_aead serves only the AF_ALG userspace crypto socket interface — it is not used by the kernel crypto subsystem that backs dm-crypt, WireGuard, or mainstream TLS stacks. Blocking it has a narrow blast radius on a typical server or workstation.

Will NOT break:

At risk of breaking (all require explicitly opening socket(AF_ALG, SOCK_SEQPACKET, 0) for an AEAD algorithm):

Audit before blacklisting:

# Check for LUKS2 integrity (AEAD) in use
cryptsetup luksDump /dev/<device> | grep integrity

# Check for libkcapi-linked processes
lsof | grep libkcapi

# Check for explicit afalg engine in OpenSSL configs
grep -r afalg /etc/ssl/ /etc/openssl/

Without root — confirm the blacklist entry is present by searching the modprobe config directories:

grep -r algif_aead /etc/modprobe.d/ /lib/modprobe.d/ 2>/dev/null

Expected output if the blacklist is in place:

/etc/modprobe.d/disable-algif-aead.conf:install algif_aead /bin/false

No output means the entry is absent. This confirms the rule exists in configuration but does not prove it is being enforced.

With root — definitive test: attempt to load the module and observe whether the block fires:

sudo modprobe algif_aead && echo "NOT BLOCKED" || echo "BLOCKED"

BLOCKED confirms the blacklist is effective — modprobe runs /bin/false instead of loading the module and exits non-zero. NOT BLOCKED means the blacklist is missing or not active. Note that lsmod | grep algif_aead is not a sufficient check: no output only means the module is not currently loaded, not that it cannot be loaded on demand. The modprobe blacklist entry persists across reboots. Note that this workaround blocks any legitimate use of AF_ALG AEAD sockets — in practice this affects only specialized cryptographic applications that explicitly use the kernel's userspace crypto API; standard TLS and disk encryption are unaffected.

For container environments where the module blacklist cannot be applied at the host level, apply a seccomp profile that blocks socket(AF_ALG, ...) calls from within container workloads.

Alternative No-Reboot Mitigation: BPF-LSM

If the module cannot be unloaded (e.g., algif_aead is =y built-in) and a patched kernel is not yet available, Cloudflare documented a BPF-LSM approach that denies socket_bind LSM hook calls to non-allowlisted processes attempting to bind an AF_ALG socket. This operates at the LSM layer in kernel space — it does not require the module to be absent, only blocks the specific bind operation that initiates the AEAD session. The technique requires a kernel built with CONFIG_BPF_LSM=y (available in most modern distributions) and loading a BPF-LSM program via bpftool or Cilium Tetragon. See Cloudflare's write-up for the implementation detail. This is a defense-in-depth control suitable for built-in =y kernels pending a patched package from the distribution vendor.

Vendor Patch Status

As of 2026-05-08, patches are available from all major distribution vendors. Update via your standard package manager (dnf update kernel, apt-get dist-upgrade, zypper patch) and reboot to activate the fixed kernel.

Ubuntu note: Canonical's current fix disables the vulnerable algif_aead module via a kmod package update — the same effect as the manual blacklist workaround above. A full kernel patch is expected at a later date. All supported Ubuntu releases from 14.04 through 25.10 are covered; 26.04 (Resolute) is not affected.

AlmaLinux note: AlmaLinux shipped patches on May 1, 2026 — ahead of RHEL upstream — using independent backports. Kitten 10 (the rolling preview) is also patched (kernel-6.12.0-225.el10). Important for all RHEL-family distributions (RHEL, AlmaLinux, Rocky Linux, CentOS Stream, CloudLinux): algif_aead is compiled directly into the kernel (CONFIG_CRYPTO_USER_API_AEAD=y), so the modprobe blacklist workaround is ineffective — applying the patched kernel is the only mitigation.

SUSE note: SUSE released patches for all maintained SUSE Linux Enterprise and openSUSE Leap distributions on May 3, 2026. SLES 16.0 received its patch one day earlier, on May 2. openSUSE Leap 15.6 and 15.5 share advisories with the corresponding SLES 15 SP releases. SLES 11 is not affected (kernel predates the vulnerable 2017 commit).

RHEL 7 note: Red Hat Enterprise Linux 7 ships kernel 3.10.x, which predates the vulnerable commit (72548b093ee3, merged July 2017, first appearing in kernel 4.14). Standard RHEL 7 is not affected. The exception is environments running a custom or third-party kernel on RHEL 7 userland — for example, Oracle Linux 7 with the UEK (Unbreakable Enterprise Kernel, based on 5.15.x) is affected via the UEK path and requires patching. CloudLinux 7 (also 3.10-based) is similarly not affected. If you have received questions about RHEL 7, the answer is: default kernel — not vulnerable; custom/UEK kernel — check the kernel version.

Wind River note: Wind River ships two distinct product families that are often confused. Wind River Linux and eLxr Pro are Linux-based distributions — these are affected and rated "significantly impacted" by Wind River. VxWorks is Wind River's proprietary real-time OS (RTOS) with its own kernel; it has no Linux kernel code and is not affected. Wind River Studio Developer and Cloud Platform (which sit on top of either Linux or VxWorks depending on the deployment) are rated limited impact. The module blacklist workaround (echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf) applies to Linux-based Wind River products only. Kernel patches are expected in upcoming Hot Fix/RCPL releases. Consult Wind River's advisory page for current status.

BSD family note: The algif_aead module and the AF_ALG socket interface are Linux kernel subsystems with no equivalent in BSD kernels. FreeBSD, OpenBSD, NetBSD, and macOS/iOS (XNU) are not affected regardless of version. Any system running a BSD-derived kernel — including embedded and networking appliances built on BSD — is out of scope for this CVE.

VMware/Broadcom note: Broadcom confirmed no VMware products are exploitable. ESXi does not run a Linux kernel; Photon OS (the basis for all VMware appliances including vCenter Server, NSX, and Aria Suite products) does not load algif_aead; and VMware NSX's restricted administrative shell architecture structurally blocks the local privilege escalation threat model regardless. Last updated by Broadcom: May 13, 2026.

Recommended Actions

1. Apply your distribution's patched kernel package — Ubuntu, RHEL, Amazon Linux, SUSE, AlmaLinux, Rocky Linux, Debian, and derivatives are all releasing updates. Check your package manager for kernel security updates.

2. Immediate interim mitigation — blacklist the vulnerable algif_aead module before a patched kernel is available:

   echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
   rmmod algif_aead 2>/dev/null
   

   This prevents the module from loading. Verify with lsmod | grep algif_aead.

3. Prioritize multi-tenant environments — Kubernetes nodes, CI/CD runners, shared hosting systems, and any environment where untrusted users can run code are at highest risk. Exploit escalates any container or shell access to root on the host kernel.

4. Review container security posture — Assess whether workloads running as non-root in containers can still load AF_ALG sockets. Apply seccomp profiles that block socket(AF_ALG, ...) if the module blacklist cannot be applied immediately.

5. Dirty Frag (CVE-2026-43284 / CVE-2026-43500) — A follow-on pair in the same attack class; limited in-the-wild exploitation confirmed. See the Dirty Frag section below for details and interim mitigations.

6. Verify the patch is applied — After updating, confirm the running kernel version matches or exceeds the fixed version for your LTS branch (see Affected Versions table above): uname -r. Note that rpm -q kernel (RHEL-family) or dpkg -l linux-image-* (Debian/Ubuntu) shows what is installed — a reboot is required to activate the new kernel. If uname -r still shows the old version, the system is still running the vulnerable kernel despite the package being installed.

7. Harden the kernel baseline — Copy Fail is one vulnerability. For a systematic approach to reducing the attack surface across the full class of Linux kernel local privilege escalation flaws, see Hardening the Linux Kernel: Defense in Depth Against Privilege Escalation, which covers the Kernel Self Protection Project (KSPP) baseline — including the compile-time and runtime controls most directly relevant to this vulnerability class.

Telecom and Network Infrastructure Vendors

5G core and RAN infrastructure runs as containerized network functions (CNFs) or virtualized network functions (VNFs) on multi-tenant Linux hosts. A compromised VNF — reachable through a management plane vulnerability or a misconfigured container — could use Copy Fail to escape the container namespace and obtain root on the underlying host. Telecom operators should verify the Linux kernel version on every host running network functions and apply vendor guidance where available.

The table below summarizes advisory status as of May 13, 2026. "No public portal" means the vendor does not maintain a publicly indexed CVE advisory database — contact your account team or support channel directly.

Follow-On: Dirty Frag (CVE-2026-43284, CVE-2026-43500)

On May 7, 2026 — one week after Copy Fail's KEV listing — researcher Hyunwoo Kim disclosed a second pair of Linux kernel local privilege escalation vulnerabilities in the same attack class. The embargo was broken by an unrelated third party, prompting early coordinated release.

Dirty Frag chains two separate page-cache write primitives:

How It Works

The root cause is the same attack surface: when splice(2) / sendfile(2) is used to pass paged buffers (including page-cache pages of files on disk) into a kernel socket, and the kernel performs in-place decryption over those pages without taking private ownership first, an unprivileged process can retain references to the resulting plaintext. The decryption operation writes back into the page cache of the file, yielding a write primitive into any readable file — identical in outcome to Copy Fail.

CVE-2026-43284 uses the esp4/esp6 IPsec modules' receive-path decryption. CVE-2026-43500 uses the rxrpc protocol's packet reassembly path. Both are exploitable without root and without race conditions.

Impact and Patch Status

A working public PoC exists. Any unprivileged local user can gain root in a single command on current Ubuntu, Debian, Arch, and Fedora. AlmaLinux shipped patches on May 7, 2026. The ESP (CVE-2026-43284) kernel patch was officially released upstream on May 8, 2026; the rxrpc (CVE-2026-43500) patch remained pending upstream as of May 8, 2026. Ubuntu has published a dedicated Dirty Frag advisory with mitigations. TuxCare/KernelCare has released live patches for Dirty Frag — a no-reboot option for KernelCare subscribers.

Limited in-the-wild exploitation has been confirmed. Microsoft reported (May 8, 2026) limited activity where privilege escalation via su is observed, consistent with Dirty Frag or Copy Fail techniques. The observed post-exploitation pattern involves modifying GLPI IT asset management authentication files to harvest session data after obtaining root. No specific threat actor has been attributed.

Dirty Frag is not yet in the CISA KEV catalog. Given the confirmed active exploitation, a KEV listing is expected. Watch this page for updates.

Interim Mitigation

If esp4/esp6 and rxrpc are not required:

# Block ESP modules (only if IPsec is not in use)
echo "install esp4 /bin/false" > /etc/modprobe.d/disable-esp4.conf
echo "install esp6 /bin/false" >> /etc/modprobe.d/disable-esp4.conf
rmmod esp4 2>/dev/null; rmmod esp6 2>/dev/null

# Block rxrpc (only if AFS/OpenAFS is not in use)
echo "install rxrpc /bin/false" > /etc/modprobe.d/disable-rxrpc.conf
rmmod rxrpc 2>/dev/null

Do not apply the esp4/esp6 block on hosts using IPsec (VPN gateways, WireGuard does not use esp4/esp6 and is unaffected). Verify IPsec usage with ip xfrm state before blacklisting.

Fragnesia (CVE-2026-46300) — A Third Vulnerability in This Class

Shortly after Dirty Frag, William Bowling of V12 Security disclosed Fragnesia (CVE-2026-46300), a third local privilege escalation in the same page-cache write class. Fragnesia targets a distinct logic flaw in the XFRM ESP-in-TCP ULP subsystem (net/xfrm/espintcp.c). The root cause is in the core socket-buffer code: skb_try_coalesce() failed to propagate the SKBFL_SHARED_FRAG marker when transferring paged fragments between buffers, allowing the kernel to lose track of the fact that a fragment was externally backed. This enables arbitrary byte writes into the page cache of readable files — the same outcome as Copy Fail and Dirty Frag but via an independent kernel code path.

Relationship to Dirty Frag: Fragnesia shares the same attack class (page-cache write → setuid binary corruption → root shell) and the same mitigation, but differs in several ways:

• Kernel subsystem: XFRM ESP-in-TCP (net/xfrm/espintcp.c), vs. ESP/rxrpc (Dirty Frag) vs. algif_aead (Copy Fail)
• Mechanism: AES-GCM keystream manipulation, vs. in-place decryption (Dirty Frag) vs. AEAD scratch write (Copy Fail)
• Discoverer: William Bowling / V12 Security, vs. Hyunwoo Kim (Dirty Frag) vs. Taeyang Lee / Theori (Copy Fail)

Fragnesia is sometimes described as a variant of Dirty Frag rather than a distinct vulnerability. Both descriptions are defensible: the attack class, exploitation outcome, and mitigation are identical; the underlying code path and patch are separate, which is why it received its own CVE.

The affected scope mirrors Dirty Frag: every Linux kernel before approximately May 13, 2026 is vulnerable. A patch was submitted upstream by that date. AlmaLinux has patched kernels available in testing as of May 13, 2026; other distribution patches are expected to follow. No CISA KEV entry has been added as of this writing.

Interim mitigation: The mitigation for Fragnesia is identical to Dirty Frag — the same three-module block covers all three CVEs (CVE-2026-43284, CVE-2026-43500, CVE-2026-46300). The espintcp code path is built directly into the esp4/esp6 subsystem and is not a standalone loadable module; blocking esp4 and esp6 closes the Fragnesia attack surface automatically. Apply the commands in the Dirty Frag Interim Mitigation section above — no additional steps are required for Fragnesia.