Dirty Frag (CVE-2026-43284): Linux Kernel LPE — blacklist the modules, weigh IPsec, protect customer stacks

TL;DR — the 90-second summary

Affected?

All Linux kernels since 2017, including kernel 7.0.4. Confirmed: Ubuntu 24.04.4, RHEL 10.1, CentOS Stream 10, AlmaLinux 10, Fedora 44, openSUSE Tumbleweed. SLES 11 SP4 LTSS Extreme Core not affected.

Risk?

Universal local privilege escalation to root via the chained page-cache write flaws in xfrm-ESP and RxRPC. Public PoC available.

Immediate action?

Block modules esp4, esp6, rxrpc via /etc/modprobe.d/dirtyfrag.conf and unload them with rmmod. AWS additionally recommends ipcomp4, ipcomp6, and disabling unprivileged user namespaces.

Recommendation?

German Mittelstand: deploy module blacklist now, distribution patch within 7 days. Enterprise/Kubernetes: add detection hooks on XFRM netlink and rebuild the worker node image. NixOS: declarative path via boot.blacklistedKernelModules.

Criticality?

High — CVSS 7.8 CISA, 8.8 SUSE (attack complexity diverges). See badge in the page header.

 

What is the problem?

Dirty Frag (CVE-2026-43284) has been officially tracked since 8 May 2026 (CVE number first issued by AlmaLinux). The UMich Information Assurance bulletin from 7 May 2026 describes it as a universal Linux LPE: a local user with no extra privileges can reach root in a short time. The public proof-of-concept lives at github.com/V4bel/dirtyfrag.

According to UMich, all Linux versions released since 2017 are affected, including kernel 7.0.4. That's an unusually broad reach, comparable to Copy Fail, which we discussed in the cluster in early May (CVE-2026-31431). Comparable not in the technical detail, but in the consequence: every Linux machine that isn't mitigated or patched is today a one-step target for local escalation.

The oss-security disclosure from 7 May 2026 gives the technical anatomy: Dirty Frag is a chain of two separate page-cache write flaws, one in xfrm-ESP (IPsec fast path with MSG_SPLICE_PAGES no-COW) and one in RxRPC (the kAFS transport layer). The chain becomes reachable via the XFRM user netlink interface, which auto-loads the relevant kernel modules on demand. That's why the mitigation targets exactly these three modules: they are the entry gate to the chain, even on hosts that use neither IPsec nor kAFS actively.

Disclosure ran uncoordinated: the linux-distros embargo was set for 12 May 2026, a third party prematurely published the ESP half on 7 May, which forced the researcher into immediate full disclosure. That's why patches weren't ready at public disclosure and CVE IDs hadn't been issued — and why the module blacklist mitigation was the only available defense in the first few days. As of 11 May 2026, the ESP patch is in most distributions, the RxRPC patch is still partially unmerged — the module blacklist for rxrpc therefore remains necessary for the time being.

Who is affected?

The reach is unusually broad because the two chained flaws sit in kernel paths that ship in practically every mainstream Linux. What matters isn't the userland but the kernel and the module auto-load behavior through XFRM netlink.

LPE flaws aren't a pure server matter. Three scenarios where Dirty Frag hits the German Mittelstand directly:

• Developer and CI machines with shared accounts. If you run build runners, jump hosts, or test VMs with multiple users, you've gained an escalation path between standard user and root that shouldn't be there.
• Container hosts with tenant separation. When a workload runs with reduced privileges (the rule in a clean Kubernetes setup), Dirty Frag breaks that separation. Container escapes via kernel LPEs are textbook — we derived this in more detail in the Copy Fail post.
• Web servers with a compromised application. An application that itself only runs as www-data or similar gains, with Dirty Frag, the lever to full control of the host — even on systems whose discipline was specifically about running applications unprivileged.

The universal reach (all kernels since 2017) means: practically every productive Linux machine in the Mittelstand is affected, unless mitigation or patch has already been applied.

Impact

Dirty Frag is a local privilege escalation. RCE or remote escalation isn't directly possible; the exploit requires existing code execution in user space. But in the Mittelstand stack that precondition is so low-friction to reach that the rating still lands in the high range.

The CVSS ratings differ depending on the evaluator:

SUSE sets Attack Complexity to Low (CISA: High), at the same local vector and scope-changed. Both classify the issue as Important. We follow the SUSE reading in our internal risk assessment, because the public PoC and the trivial auto-load precondition make Attack Complexity effectively Low in practice, not High.

What that means operationally:

• Container escape effectively possible. Every compromised pod on an unpatched host can gain root on the node. From there, the entire worker node — and through it, the cluster — is exposed.
• CI/CD runners as a high-risk target. Self-hosted GitHub runners, GitLab runners, and Jenkins agents regularly execute untrusted code. A single compromised pipeline is enough — we've covered elsewhere in detail why the CI pipeline is the largest concentration point for escalations in the stack.
• Shared hosting and multi-tenant VPS. A classic entry point for cross-tenant escalation.
• Compliance consequences. Anyone operating under ISO 27001 or NIS-2 has an incident-assessment obligation as soon as an exploit becomes publicly available, regardless of the detection status.

On the business side: downtime due to reboot is the most likely direct impact. Data loss is not a realistic scenario with clean mitigation; the reputational question only arises if an incident occurs before the patch. The eight days between disclosure (7 May) and the first distribution patch (AWS, 9 May) are exactly the window in which module blacklist and PoC validation make the difference.

Mitigation and immediate actions

The short answer: deploy the distribution patch and reboot. Where the patch isn't available yet (or the maintenance window is further out), block the vulnerable kernel modules. Both workarounds take effect at runtime.

Quick start (copy/paste)

For Linux hosts without IPsec and without kAFS — the German Mittelstand majority — four lines are enough for immediate stopgap mitigation:

# 1. Unload the modules live if loaded
sudo modprobe -r esp4 esp6 rxrpc ipcomp4 ipcomp6 2>/dev/null

# 2. Persist the five-module blacklist (AWS recommendation)
cat <<EOF | sudo tee /etc/modprobe.d/dirtyfrag.conf
install esp4     /bin/false
install esp6     /bin/false
install rxrpc    /bin/false
install ipcomp4  /bin/false
install ipcomp6  /bin/false
EOF

# 3. Disable unprivileged user namespaces
echo -e "kernel.unprivileged_userns_clone = 0\nuser.max_user_namespaces = 0" | sudo tee /etc/sysctl.d/99-dirtyfrag.conf
sudo sysctl --system

# 4. Validate that the modules no longer load
lsmod | egrep '^(esp4|esp6|rxrpc|ipcomp4|ipcomp6)' || echo "Mitigation active."

On NixOS / Talos / Flatcar use the declarative variant (see further below). For hosts running productive IPsec or kAFS, follow the trade-off block at the end of this section first — secure an alternative path, then mitigate.

Deploy the patch where available

# Amazon Linux 2023 (patch available since 09 May 2026)
sudo dnf upgrade -y kernel
sudo reboot

# Amazon Linux 2
sudo yum update -y kernel
sudo reboot

# SUSE Linux Enterprise Real Time 15 SP7 (live patch released)
sudo zypper patch --category security
# Reboot-free for kernel-livepatch-SLE15-SP7-RT_Update_13

# Other mainstream distros: watch the ongoing backports
# Debian/Ubuntu: apt list --upgradable | grep linux-image
# RHEL/AlmaLinux/Rocky: dnf check-update kernel

Module blacklist (UMich variant, three modules)

The UMich recommendation blocks the three directly vulnerable modules:

# Create /etc/modprobe.d/dirtyfrag.conf
cat <<EOF | sudo tee /etc/modprobe.d/dirtyfrag.conf
install esp4  /bin/false
install esp6  /bin/false
install rxrpc /bin/false
EOF

# Check whether modules are currently loaded
lsmod | egrep '^(esp4|esp6|rxrpc)'

# Unload them if loaded
sudo rmmod esp4 esp6 rxrpc

AWS extension (five modules plus user namespace block)

The AWS Security Bulletin AWS-2026-027 extends the blacklist with ipcomp4 and ipcomp6 (same xfrm module family, auto-loaded through the same netlink path). Plus two flanking steps:

# Extended module blacklist
cat <<EOF | sudo tee /etc/modprobe.d/dirtyfrag-aws.conf
install esp4     /bin/false
install esp6     /bin/false
install rxrpc    /bin/false
install ipcomp4  /bin/false
install ipcomp6  /bin/false
EOF

# Disable unprivileged user namespaces
cat <<EOF | sudo tee /etc/sysctl.d/99-dirtyfrag.conf
kernel.unprivileged_userns_clone = 0
user.max_user_namespaces = 0
EOF
sudo sysctl --system

# Sharpen monitoring on anomalous setuid executions
# (auditd, Falco, Tetragon — see Detection section)

For Amazon Linux hosts this extended list is the official recommendation; on other distributions it works as a clean defense-in-depth variant.

NixOS — declarative variant

On NixOS /etc/modprobe.d/ is a symlink into the Nix store; manual edits are discarded on the next nixos-rebuild. The correct path is through the NixOS configuration:

{ pkgs, ... }:
{
  boot.extraModprobeConfig = ''
    install esp4    ${pkgs.coreutils}/bin/false
    install esp6    ${pkgs.coreutils}/bin/false
    install rxrpc   ${pkgs.coreutils}/bin/false
    install ipcomp4 ${pkgs.coreutils}/bin/false
    install ipcomp6 ${pkgs.coreutils}/bin/false
  '';

  boot.blacklistedKernelModules = [
    "esp4" "esp6" "rxrpc" "ipcomp4" "ipcomp6"
  ];

  boot.kernel.sysctl = {
    "kernel.unprivileged_userns_clone" = 0;
    "user.max_user_namespaces" = 0;
  };
}

# afterwards
sudo nixos-rebuild switch

Three properties that NixOS handles better than the classic distribution pattern:

• Path correctness. On NixOS /bin/false doesn't exist, the Nix store path is the only way that actually takes effect after nixos-rebuild. Copy-pasting the UMich instructions 1:1 means errors in the modprobe log instead of mitigation on NixOS.
• Atomic and rollbackable. After sudo nixos-rebuild switch the mitigation is part of the current system generation. When the distribution patch lands, just remove the block from the config and rebuild. If something breaks: sudo nixos-rebuild --rollback switch.
• Declarative multi-host rollout. Via deploy-rs, colmena, NixOps, or nixos-rebuild --target-host, the configuration rolls out across all declared hosts in one wave. The audit question „which hosts carry the mitigation, which don't?“ becomes a git question, not a spot-check question.

Trade-offs — what breaks

IPsec. The modules esp4 and esp6 are part of the IPsec infrastructure for IPv4 and IPv6. If you run site-to-site VPNs or host-to-host IPsec, the mitigation breaks the ESP path. Alternative connectivity must be in place or the application must be briefly interrupted before mitigation.

kAFS. The rxrpc module is the transport layer of the kernel AFS implementation. If you run kAFS in production, you lose filesystem access. The OpenAFS implementation is explicitly not affected; that's the more common case in the Mittelstand.

IP compression.ipcomp4 and ipcomp6 are rarely used productively; the additional block is usually inconsequential. If you do use IPComp (combined with IPsec on bandwidth-critical links), you need an alternative path before mitigation.

Rollback. The module blacklist can be reverted with sudo rm /etc/modprobe.d/dirtyfrag*.conf and a reboot. Sysctl stopgap: sudo rm /etc/sysctl.d/99-dirtyfrag.conf && sudo sysctl --system.

Detection and verification

Detection on Dirty Frag answers five operational core questions:

• Which modules are loaded on which hosts? — inventory via lsmod and SBOM.
• Which hosts are exposed? — check against ip xfrm state and the auto-load path.
• How do we check container hosts? — Tetragon/Falco hooks on NETLINK_XFRM and AF_RXRPC from container processes.
• How do we validate the mitigation? — reproduce the public PoC before and after the stopgap, isolated test VM, exit-code comparison.
• How do we detect active exploitation? — auditd on XFRM netlink socket creation, Tetragon correlation init_module after NETLINK_XFRM, syslog patterns on anomalous setuid executions (per AWS guidance).

Three layers in the concrete implementation: check whether the vulnerable modules are loaded; check whether the XFRM auto-load path has been used; check whether the mitigation actually takes effect.

Module and kernel status

# Are the five relevant modules loaded?
lsmod | egrep '^(esp4|esp6|rxrpc|ipcomp4|ipcomp6)'

# Check kernel version (everything since 2017 is affected)
uname -r

# Trace distribution patch date
dpkg -l linux-image-$(uname -r) | tail -1   # Debian/Ubuntu
rpm -qi kernel-$(uname -r | sed 's/\.[^.]*$//')  # RHEL/AlmaLinux

# Check whether the XFRM symbols are exported in the running kernel at all
grep -E '(xfrm_user|esp_input|rxrpc_recvmsg)' /proc/kallsyms | head

# Inspect the auto-load module chain (what hangs off the xfrm stack?)
modprobe --show-depends esp4 esp6 rxrpc ipcomp4 ipcomp6

# IPsec active? (trade-off check before mitigation)
sudo ip xfrm state
sudo ip xfrm policy

Audit logs on XFRM netlink

# Sharpen auditd on the XFRM netlink socket
sudo auditctl -a always,exit -F arch=b64 -S socket -F a0=16 -F a1=3 -k xfrm-netlink

# Retrospective check
sudo ausearch -k xfrm-netlink -ts recent

# rxrpc socket activity (AF_RXRPC = 33) on the running system
sudo ss -A inet,inet6 -p | grep -i rxrpc

Falco rule as an alternative to Tetragon

If you run Falco instead of Tetragon, the same signal path is covered by two combined rules — one for the XFRM netlink entry, one for the RxRPC socket. Neither has a use case in regular application containers:

- rule: Suspicious XFRM netlink socket from container
  desc: Detect creation of NETLINK_XFRM sockets from container processes — likely Dirty Frag entry probe
  condition: >
    evt.type = socket and
    container.id != host and
    evt.arg[0] = 16 and
    evt.arg[2] = 6
  output: >
    NETLINK_XFRM socket opened from container
    (pod=%k8s.pod.name ns=%k8s.ns.name container=%container.name
     proc=%proc.cmdline pid=%proc.pid user=%user.name)
  priority: WARNING
  tags: [container, mitre_privilege_escalation, cve-2026-43284]

- rule: Suspicious AF_RXRPC socket from container
  desc: Detect creation of AF_RXRPC (kAFS) sockets from container processes — second stage of Dirty Frag
  condition: >
    evt.type = socket and
    container.id != host and
    evt.arg[0] = 33
  output: >
    AF_RXRPC socket opened from container
    (pod=%k8s.pod.name ns=%k8s.ns.name container=%container.name
     proc=%proc.cmdline pid=%proc.pid user=%user.name)
  priority: CRITICAL
  tags: [container, mitre_privilege_escalation, cve-2026-43500]

Falco runs as a DaemonSet, Tetragon TracingPolicies are declared via CRDs. In clusters where Cilium is already deployed, Tetragon is the more direct path; otherwise Falco. Both write hits to JSON logs that a SIEM aggregates by pod identity. The second rule (AF_RXRPC) should be classified as CRITICAL: RxRPC is practically never used in production across the German Mittelstand, so hits there are almost always escalation attempts.

Tetragon hook on the exploit path

The public PoC triggers two syscall sequences: socket(AF_NETLINK, …, NETLINK_XFRM) followed by a module load, plus, if the second stage runs, socket(AF_RXRPC). Neither has a use case in regular application containers.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-dirty-frag-sequence
spec:
  kprobes:
    - call: "__x64_sys_socket"
      syscall: true
      args:
        - index: 0
          type: "int"
        - index: 2
          type: "int"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Equal"
              values: ["16"]   # AF_NETLINK
            - index: 2
              operator: "Equal"
              values: ["6"]    # NETLINK_XFRM
        - matchArgs:
            - index: 0
              operator: "Equal"
              values: ["33"]   # AF_RXRPC
    - call: "__x64_sys_init_module"
      syscall: true

Correlated in the SIEM pipeline (or directly in Tetragon output, keyed by pid/tgid): if a pod with no IPsec or kAFS need opens an XFRM netlink socket and shortly afterwards an init_module call fires on the host, that's a high-probability Dirty Frag entry signal.

Validating the mitigation

We consider a host clean only when the public PoC fails after the mitigation. The repo is at github.com/V4bel/dirtyfrag. The PoC is executed in an isolated user session and the result (exit code, possible UID change) is logged. Only then does the host receive the cleanup flag in our inventory.

# PoC in an isolated test session
git clone github.com/V4bel/dirtyfrag /tmp/dirtyfrag
cd /tmp/dirtyfrag
# Setup per README
./run_exploit.sh
# Expectation after mitigation: non-zero exit, no root shell drop

Important: PoC reproduction doesn't belong on production hosts. Validation needs an isolated test VM with identical distribution and kernel version.

Operator recommendation

The recommendation depends on the setup. Four scenarios, four answers — with an operational decision grid upfront:

Decision grid: when to mitigate now, when to wait for a maintenance window?

• Mitigate immediately (today) if the host runs multi-tenant workloads, holds CI/CD runners, runs shared workers, allows unprivileged multi-user sessions, or hosts an already compromised application. Microsoft's active-attack classification makes this category a same-day obligation.
• Maintenance window acceptable (next 48 hours) if the host runs as an isolated single-tenant system, no foreign users run code, and neither IPsec nor kAFS is documented as productive.
• Patch wave within the next 7 days is enough if the host is a plain workstation or sealed single-user server with no network-exposed services running unknown code.
• IPsec host? Secure an alternative path first. If you run productive ESP tunnels, don't mitigate blindly — WireGuard failover or a maintenance window is mandatory.

These four lines are concretized in the scenarios below.

German Mittelstand with classic VMs or bare metal

Module blacklist immediately, distribution patch in the next maintenance window (within 7 days at the latest). If you don't have a defined patch window, establish a fixed weekly slot now. The blacklist as a stopgap is fine for 24 to 72 hours, but it isn't a permanent state. IPsec check before the mitigation, then stage 1 pre-prod, stage 2 production.

Shared hosting and multi-tenant VPS

Highest priority. A multi-tenant host with a compromised customer account is two steps gone with Dirty Frag — unprivileged account → LPE → cross-tenant escalation. Deploy the five-module blacklist immediately, plus the user namespace sysctl. If the hosting stack uses classic cgroups-based isolation, the K8s lateral-movement logic (see Copy Fail in Kubernetes) applies in spirit.

Enterprise with change management

Run two tracks in parallel: standard patch pipeline for production via maintenance window, stopgap mitigation (module blacklist plus sysctl) for all hosts that can't be patched within 48 hours. Maintain compliance documentation in parallel: affected hosts, stopgap status, patch status, validation result. Auditable.

Kubernetes clusters (self-managed and managed)

Decision grid for Kubernetes hosts:

• Multi-tenant clusters, shared workers, or CI/CD runner nodes → rebuild the worker image with the five-module blacklist now, rolling drain.
• Managed K8s (AKS/EKS/GKE) on Amazon Linux or AlmaLinux base → set the provider channel to the patched release, roll the node pool.
• Managed K8s on Ubuntu/Debian base → maintain the module blacklist via cloud-init or bootstrap script until the provider image is patched.
• Privileged DaemonSets sharing a base layer with application pods → inspect the lateral-movement path (analog logic to Copy Fail in Kubernetes).

For self-managed clusters, rebuild the worker node image with the module blacklist entries, then per node kubectl drain <node> --ignore-daemonsets --delete-emptydir-data, reboot, kubectl uncordon. Check PodDisruptionBudgets beforehand. For Managed K8s (AKS, EKS, GKE) set the provider channel to the patched node-image release and let the node pools roll — EKS customers on Amazon Linux 2023 are covered since 09 May via the standard upgrade pattern. Tighten detection hooks (see Detection section) on the XFRM netlink path until 100 percent of nodes are patched. PodSecurity standard at minimum restricted.

VPN and IPsec gateways

Validate the trade-off first. Before esp4/esp6 get blocked, it has to be clear whether site-to-site tunnels or host-to-host IPsec are running in production. Three paths: first, bring up a WireGuard failover path on layer 3 and only deploy the IPsec module blacklist after a successful routing switch; second, install the patched kernel directly (available for Amazon Linux / AlmaLinux / Rocky) and keep the module blacklist only for rxrpc/ipcomp*; third, plan a maintenance window with brief tunnel downtime and run stopgap + reboot together during the window. Keep the detection hook on XFRM netlink sharp in parallel, because an attacker on a lateral-movement wave targets gateways first.

NixOS hosts and declarative stacks

If you run NixOS or another declarative host stack (Talos, Flatcar), you have two advantages that matter here. First: the mitigation is a code change in configuration.nix, not a config edit on the live system, it goes through code review and CI. Second: the previous generation stays available in the bootloader. If the module blacklist breaks a productive function (e.g. IPsec on a host that does use it), a reboot into the old generation is enough. This reversibility is missing from classic apt/dnf hosts.

What we actually did

At the UMich notification on 7 May we ran the same pattern internally as with Copy Fail: SBOM reconciliation across all customer stacks, Linux hosts with kernel versions since 2017 (so practically all) marked as affected, IPsec and kAFS usage checked per stack.

• SBOM inventory on 7 May, 19:42. Inventory through our SBOM pipeline: which host runs which kernel, which distribution, which patch date. Plus ip xfrm state analysis for IPsec and lsmod | grep -E 'kafs|rxrpc' for kAFS. Clarity on every host in the fleet within 90 minutes.
• IPsec and kAFS check per customer stack. Most customer stacks run neither IPsec in the kernel stack (site-to-site tunnels use WireGuard or dedicated VPN appliances) nor kAFS (OpenAFS is the rare standard in the German Mittelstand, kAFS rarer still). The mitigation was therefore low-risk for most stacks.
• Stopgap mitigation on 7 May (pre-prod) and 8 May (production). Three-module blacklist on non-critical build runners and test VMs during 7 May, production hosts in the 8 May maintenance window. NixOS hosts went through the declarative variant (see Mitigation section), classic distribution hosts via the UMich procedure.
• AWS extension on 8 May, afternoon. After the AWS bulletin, we added ipcomp4, ipcomp6 and set the user namespace sysctl. Five-module blacklist instead of three.
• Per-host validation. V4bel/dirtyfrag PoC run against mitigated hosts in an isolated test VM. A host counts as clean for us only when the exploit fails.
• Distribution patch follow-up. From 9 May 2026 for Amazon Linux hosts via the standard update pipeline. As soon as the patch lands in the respective channels (Debian stable, Ubuntu LTS, RHEL family), it's deployed; the stopgap is only retracted after successful PoC validation against the patched kernel. Patch and stopgap overlap deliberately.
• What we deliberately didn't do. No mitigation on IPsec hosts without alternative connectivity. No generic hardening actions „while we're at it“, so that the validation of the actual mitigation stays clean.

This routine is exactly what we run for customers as part of DevSecOps as a Service and the External IT Department. Methodically, Dirty Frag, Copy Fail, and the image audit after an IDS alarm sit in the same fabric: SBOM routine, isolated PoC validation, documented rollout.

Technical deep dive

Dirty Frag is a chain of two separate page-cache write flaws in different subsystems of the Linux kernel. Only the chain makes the universal LPE possible; individual parts alone would be less exploitable.

Component 1: xfrm-ESP fast path

The ESP implementation in net/ipv4/esp4.c and net/ipv6/esp6.c has used a MSG_SPLICE_PAGES fast path since commit cac2661c53f3 (January 2017). Data is fed into the ESP encapsulation path via page splicing without copy-on-write. That saved CPU in IPsec throughput and was a clean optimization at the time.

The problem: under certain race conditions, the ESP path writes into a page that belongs to the page cache of a different file. Because no COW is triggered, the modification lands directly in the shared page cache entry, without a disk write, without a trace in the filesystem. Conceptually that's comparable to the K8s variant vector in Copy Fail: shared page cache becomes the manipulation layer.

The mainline fix landed in the netdev tree on 7 May 2026 as commit f4c50a4034e6: a new SKBFL_SHARED_FRAG flag forces COW when the page is shared. Distribution backports have been rolling since.

Component 2: RxRPC transport

net/rxrpc/ is the kernel implementation of the Rx-RPC protocol, primarily the transport layer for kAFS (kernel AFS). RxRPC uses a similar page-splicing mechanism to ESP, with the same structural consequences once the implementation writes into a shared buffer.

The RxRPC component has been vulnerable since June 2023, the corresponding upstream patch is partially still unmerged as of 11 May 2026. That's exactly why the module blacklist for rxrpc remains necessary even after the ESP patch.

Entry gate: XFRM user netlink auto-load

The actual trick — and the reason practically every host is affected — sits in the XFRM user netlink interface. An unprivileged process can request an operation via a NETLINK_XFRM socket that requires the kernel to load the ESP or RxRPC module. The auto-load triggers even if the host uses neither IPsec nor kAFS in production. That's also why the mitigation targets three (UMich) or five (AWS) modules: not the usage paths, but the entry barrier is closed.

Why ipcomp4 and ipcomp6 belong with them

The ipcomp4 and ipcomp6 modules belong to the same xfrm module family as ESP and are auto-loaded through the same netlink path. They aren't directly part of the currently known chain, but they're a plausible follow-up exploit vector if another page-cache write flaw is found in the same family. AWS recommends preemptive blocking for exactly this reason. Once the audit work has been done, those two modules shouldn't have to be rediscovered next time.

Aspects for assessment

• No capability requirement. NETLINK_XFRM socket creation needs neither CAP_NET_ADMIN nor CAP_SYS_MODULE. Every unprivileged process can reach the path.
• Auto-load beats plain module unload. An rmmod esp4 without a blacklist only holds until the next XFRM netlink call reloads the module. That's why the install … /bin/false variant is necessary: it blocks the auto-load.
• Container namespaces don't help. User namespaces isolate UID mappings, but not the kernel code path. That's the same structural weakness as in Copy Fail — container isolation is a userspace construct, enforced by the kernel itself.
• Trade-off vector ipcomp. Anyone running IPComp in production (rare, but occasionally seen in the Mittelstand on bandwidth-critical site-to-site tunnels) loses the function. The defense-in-depth variant isn't free, just very cheap.

Conclusion

Dirty Frag is a universal Linux LPE — every kernel since 2017 is affected, public PoC available, auto-load of the vulnerable modules without capability requirement. The robust answer is the distribution patch (available for Amazon Linux since 9 May, other distros following), and until then the module blacklist for three (UMich) or five (AWS) modules plus the user namespace block.

What matters more operationally than the single CVE is the pattern behind it: for the second time in eight days, a broad kernel flaw writes into the shared page cache and is triggered through what looks like a harmless netlink path. Anyone with a clear patch cadence, a robust SBOM inventory, and a detection setup on XFRM netlink calls answers „who is affected?“ in hours, not days. Anyone rolling out the mitigation declaratively (NixOS, Talos, Flatcar) gets the bonus that retracting it after the patch is a code change, not a spot-check audit.

Realistic risk framing: high for multi-tenant hosts, CI/CD runners, and Kubernetes workers. Medium for clean single-tenant production VMs. Low for sealed single-user workstations. The discipline Dirty Frag demands isn't an exception, the next universal LPE will demand the same. The stack that answers in a structured way today answers the same way next time, just faster.