Kernel Vulnerability 'Dirty Frag' (CVE-2026-43284)

linux security

Red Hat has published bulletin RHSB-2026-003 "Dirty Frag" covering a local privilege escalation in the Linux kernel networking subsystem. The bulletin groups CVE-2026-43284 in the IPsec ESP path (Dirty Frag) and CVE-2026-46300 in the ESP-in-TCP variant (Fragnesia). Red Hat rates both as Important. Affected are RHEL 8, 9 and 10 plus OpenShift Container Platform 4. Patches are being expedited per the bulletin. Until they are in, one of the two official mitigations applies.

Update 2026-05-09: Rocky Linux has launched the optional security repository for hot-fixes outside the regular BaseOS errata. The Dirty Frag kernel hot-fix is in: for Rocky 9 as kernel-5.14.0-611.54.1.el9_7.0.1 (patch xfrm: esp: avoid in-place decrypt on shared skb frags), with parallel builds for Rocky 8 and 10. Activation steps in the linked post.

What it is

The bug lives in the kernel's IPsec code, specifically in the esp4 and esp6 modules from the XFRM subsystem. A local unprivileged account can trigger it and gain root. The "Fragnesia" variant (CVE-2026-46300) hits the ESP-in-TCP path in the same subsystem. Red Hat lists a single mitigation block in the bulletin for the whole package; the two variants below cover Dirty Frag and Fragnesia together.

ESP (Encapsulating Security Payload, RFC 4303) is the encrypting core protocol of IPsec, XFRM the kernel framework below it that manages IPsec policies and Security Associations and routes packets into the crypto modules. ESP-in-TCP (RFC 8229) encapsulates ESP in TCP so that IPsec traverses firewalls that block the native protocol.

Key facts:

  • Red Hat public date: 2026-05-07, severity Important for all CVEs listed in the bulletin
  • Affected per Red Hat: RHEL 8, 9 and 10 plus OpenShift Container Platform 4
  • Bulletin codename: Dirty Frag, alternatively Copy Fail 2

Am I affected?

On RHEL and compatible distros (Rocky Linux, AlmaLinux, CentOS Stream, Oracle Linux) the ESP modules are part of the standard kernel builds. Check whether they are currently loaded:

$ lsmod | grep -E 'esp4|esp6'

A hit means the attack path is open. No hit does not necessarily mean safe, because the modules can still be auto-loaded later.

Mitigation Variant 1: Block the ESP modules

If you do not use IPsec on the host, block the modules via modprobe. Site-to-site VPN, strongSwan, libreswan and similar setups will stop working. For such hosts the second variant is better.

Red Hat bulletin verbatim:

$ printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' | sudo tee /etc/modprobe.d/dirtyfrag.conf
$ sudo rmmod esp4 esp6 2>/dev/null || true

Validation:

$ lsmod | grep -E 'esp4|esp6'                  # empty
$ sudo modprobe -v esp4                        # "install /bin/false" and an error

See also https://docs.linuxfabrik.ch/base/system/kernel.html

Mitigation Variant 2: Disable user namespaces

Red Hat lists variant two as "No Impact to IPsec": disable unprivileged user namespaces. Bulletin wording:

$ echo "user.max_user_namespaces=0" | sudo tee /etc/sysctl.d/dirtyfrag.conf
$ sudo sysctl --system

Validation:

$ sysctl user.max_user_namespaces              # 0

Caution: breaks all workloads that need unprivileged user namespaces, in particular rootless containers (rootless Podman, unprivileged LXC) and bubblewrap-based apps like Flatpak.

Which mitigation fits?

  • VPN gateway or other IPsec host: disable user namespaces. IPsec keeps working.
  • Host with rootless containers, no IPsec: block the ESP modules. Container stack keeps working.
  • IPsec and rootless containers in parallel: no mitigation without functional loss. Apply the patch as soon as your distro ships it. The "one server, one job" mantra helps in the long run.
  • Pure application host without IPsec and without rootless containers: both mitigations are harmless, blocking the ESP modules is faster to roll back.

Container hosts

ESP modules belong to the host kernel, containers share the kernel. The mitigation must go on the host. A container-only seccomp, SELinux or AppArmor policy is not enough.

Apply the patch

Once your distro ships the fix:

$ sudo dnf check-update kernel
$ sudo dnf upgrade kernel
$ sudo systemctl reboot

Then remove the mitigation:

# Variant 1
$ sudo rm /etc/modprobe.d/dirtyfrag.conf
# Variant 2
$ sudo rm /etc/sysctl.d/dirtyfrag.conf
$ sudo sysctl --system

Rocky Linux users can install the hot-fix kernel via the security repository before the regular BaseOS errata update rolls out.

We can help

Need help patching or hardening your Linux servers? Have a look at our Service & Support plans and get in touch.

Previous Post Next Post

DE · EN