Dirty Frag (CVE-2026-43284)

Security

Dirty Frag (CVE-2026-43284)

by Dave Geoghegan 0 Comment

Dirty Frag (CVE-2026-43284): What you need to know.

On May 8, 2026, the Linux kernel project assigned CVE-2026-43284 to a vulnerability now being discussed publicly as Dirty Frag. Early public discussion describes it as a potentially broad Linux local privilege escalation issue, but the official NVD entry is more precise: the bug sits in the Linux kernel networking stack, specifically around ESP-in-UDP handling, splice-backed packet buffers, and shared skb fragments.

At the time of writing, NVD has published the record but has not yet assigned a CVSS score. Even so, kernel and security teams should treat this as a patch-priority issue because it involves kernel memory ownership assumptions and in-place modification of packet data.

The short version

Dirty Frag is caused by a mismatch in how the Linux kernel marks packet buffers that contain pages spliced from a pipe.

TCP already marks these buffers with SKBFL_SHARED_FRAG, warning later code that the skb contains shared fragments and must be copied before modification. Some IPv4 and IPv6 UDP datagram paths did not set the same flag when using MSG_SPLICE_PAGES.

That matters because ESP input processing can decrypt packet data in place. If an ESP-in-UDP packet is backed by shared pipe pages but is not marked as shared, the kernel may treat it like privately owned skb data and modify it directly.

In plain English: the kernel could decrypt into memory it did not privately own.

Why this is risky

Kernel networking code relies heavily on ownership rules: before modifying packet data, code needs to know whether the memory is private or shared. If that bookkeeping is wrong, security boundaries can start to blur.

The official NVD description says the vulnerable path leaves an ESP-in-UDP packet made from shared pipe pages “looking like an ordinary uncloned nonlinear skb.” ESP input then takes a fast path that avoids copy-on-write and decrypts in place.

That is the heart of Dirty Frag:

  • MSG_SPLICE_PAGES can attach pipe-backed pages directly to an skb.
  • TCP correctly marks these as shared fragments.
  • IPv4/IPv6 UDP datagram splice paths did not.
  • ESP input could therefore skip copy-on-write.
  • Packet data could be modified in-place even though the skb did not privately own the backing pages.

What was fixed

The Linux kernel fix does two things:

  1. Marks IPv4/IPv6 datagram splice fragments with SKBFL_SHARED_FRAG, matching TCP behavior.
  2. Makes ESP input fall back to skb_cow_data() when that flag is present, ensuring ESP does not decrypt externally backed fragments in place.

The NVD description also notes that ESP output was intentionally left unchanged because the problematic trailer-appending path is not reachable for nonlinear skbs in the same way.

Who should care

Prioritize investigation if you run:

  • Linux systems with untrusted local users
  • multi-tenant Linux environments
  • container or Kubernetes hosts where local kernel attack surface matters
  • systems using IPsec / ESP-in-UDP paths
  • environments that allow workloads to exercise advanced networking APIs

Even if exploitation requirements turn out to be narrower than early “universal LPE” language suggests, this is still kernel-space memory ownership logic. That puts it in the category of issues defenders should not ignore.

Detection and response

There is no simple log line that proves exploitation from normal system logs. Response should focus on exposure reduction and patch verification.

Recommended steps:

  1. Track vendor advisories for your distribution or kernel provider.
  2. Patch to a kernel containing the Dirty Frag fix as soon as packages are available.
  3. Prioritize shared and multi-user systems before single-user endpoints.
  4. Review workloads that rely on IPsec, UDP encapsulation, or high-performance splice/send paths.
  5. Limit untrusted local code execution where patching is delayed.
  6. Reboot after kernel updates unless your live-patching provider explicitly confirms coverage.

Current status

  • CVE: CVE-2026-43284
  • Nickname: Dirty Frag
  • Affected component: Linux kernel networking stack, ESP/UDP skb fragment handling
  • Published: May 8, 2026
  • CVSS: Not yet provided by NVD at time of writing
  • Fix direction: Mark UDP splice fragments as shared and require copy-on-write before ESP in-place decrypt

References

  • NVD: CVE-2026-43284
  • Openwall oss-security discussion: “Dirty Frag: Universal Linux LPE”
  • Linux stable kernel commits referenced by NVD

How to fix Dirty Frag CVE-2026-43284

Customers should treat Dirty Frag as a kernel update issue. The safest fix is to install a Linux kernel version that includes the upstream patches for CVE-2026-43284.

1. Check whether your system is affected

First, check the running kernel version:Copy

uname -r

Then compare it against your Linux vendor’s advisory for CVE-2026-43284.

Affected status depends on the kernel version and whether your distribution has already backported the fix.

2. Update the kernel

Install the latest kernel updates from your distribution.

For Debian or Ubuntu-based systems:Copy

sudo apt update
sudo apt upgrade

For AlmaLinux, RHEL, CentOS Stream or Rocky Linux: Copy

sudo dnf update kernel

For older RHEL/CentOS systems:Copy

sudo yum update kernel

For SUSE-based systems:Copy

sudo zypper update kernel-default

For Arch Linux:Copy

sudo pacman -Syu

3. Reboot into the patched kernel

Kernel updates usually do not fully take effect until the system has rebooted.Copy

sudo reboot

After rebooting, confirm the active kernel:Copy

uname -r

Make sure the running kernel is the updated version, not the old vulnerable one.

4. Prioritize exposed or multi-user systems

Patch these systems first:

  • shared hosting servers
  • Kubernetes and container hosts
  • VPN/IPsec gateways
  • systems with untrusted local users
  • developer workstations running untrusted code
  • internet-facing Linux infrastructure

5. If you cannot patch immediately

If an immediate kernel update is not possible, reduce exposure until patching can be completed:

  • restrict untrusted local shell access
  • avoid running untrusted containers or workloads
  • limit access to systems using IPsec or ESP-in-UDP where possible
  • apply vendor-recommended mitigations if provided
  • monitor distribution security advisories for temporary workarounds

These mitigations should be treated as temporary. They are not a replacement for patching.

6. Verify with your vendor

Because many enterprise Linux vendors backport security fixes without changing the major kernel version, do not rely only on upstream kernel version numbers.

Check the advisory from your OS vendor, for example:

  • Ubuntu Security Notices
  • Debian Security Advisories
  • Red Hat CVE database
  • SUSE Security Advisories
  • Amazon Linux Security Center
  • Oracle Linux Errata
  • distro-specific kernel changelogs

Bottom line

Dirty Frag is a reminder that small ownership flags in kernel networking code can carry big security consequences. The bug is not about flashy malware or a misconfigured service; it is about whether the kernel knows it owns the memory it is about to modify.

For defenders, the action is straightforward: watch your vendor advisory feed, patch affected kernels, reboot, and prioritize systems where untrusted users or workloads can reach kernel networking paths.