Dirty Frag (CVE-2026-43284): the Linux kernel bug that turns read access into root

What it is

Dirty Frag is Red Hat's umbrella name for three Linux kernel CVEs: CVE-2026-43284 and CVE-2026-43500 in the networking code, plus the later Fragnesia variant CVE-2026-46300. A near-unprivileged process can write to a file it can only read by corrupting the kernel's in-memory (page-cache) copy, then use a trusted setuid file like /usr/bin/su to gain root. The vulnerable pattern dates back to roughly 2017 kernels and spans most distributions.

How it works

splice()-style operations hand the networking code a pointer into the page cache instead of copying data. Two paths — ESP (IPsec VPN traffic) and RxRPC (used by AFS) — write to that shared memory without checking it's shared. Feeding a read-only file's contents through the buggy decryption overwrites the file's cached copy; disk is untouched, but readers now see attacker content, so running su grants root.

Fragnesia is subtler: the Dirty Frag fix relies on a "this fragment is shared, copy before touching" marker. A dormant 2013 bug in the fragment-merge code silently drops that marker — harmless for thirteen years until the fix started depending on it, reopening the path.

Preconditions / Affected

Requires the ESP or RxRPC code path to be reachable. ESP is typically reached via unprivileged user namespaces; RxRPC does not need namespaces. In containers, reaching the shared node kernel means root over the whole node — working Kubernetes PoCs are published.

What to do

Check the running host, not the Dockerfile. Do not compare uname -r to the upstream version — distros backport onto old numbers (a patched RHEL 8 still reports 4.18); confirm against your vendor's fixed package version.

uname -r
lsmod | grep -E 'esp4|esp6|rxrpc'
sysctl user.max_user_namespaces

Vendor status differs per CVE: Red Hat says CVE-2026-43500 does not affect its products, while CVE-2026-43284 and CVE-2026-46300 do. Only the vendor kernel update fixes the flaw. Partial hardening: run workloads non-root, enable RuntimeDefault seccomp, restricted pod policies, limit unprivileged user namespaces. For detection, use audit/EDR to catch an unknown binary being dropped and run, immediately followed by su, and module loads of esp4/esp6/rxrpc around that time.

Caveats

• sysctl user.max_user_namespaces = 0 closes only the ESP path; RxRPC still works, so it's not full cover.
• An empty lsmod result isn't an all-clear — modules load on demand; a loaded module on a patched kernel is fine.
• Microsoft reports only limited real-world activity and notes it's hard to distinguish from the predecessor "Copy Fail" via process logs alone.

flowchart TD
  A[Unprivileged process] -->|user namespace| B[ESP path]
  A -->|no namespace needed| C[RxRPC path]
  B --> D[Missing shared-memory check]
  C --> D
  D --> E[Overwrite page-cache copy of /usr/bin/su]
  E --> F[Run su -> root]
  G[max_user_namespaces=0] -.cuts.-> B
  H[Vendor kernel patch] -.cuts.-> D