CVE-2026-43284

What it actually does

The Linux kernel ESP (IPsec) input path can decrypt in place on nonlinear socket-buffer fragments that are still shared with user-space pipe pages. UDP IPv4/IPv6 datagram splice failed to set SKBFL_SHARED_FRAG, so ESP treated the skb as privately owned, skipped copy-on-write, and overwrote pages still mapped by other tasks or the page cache. The result is cross-boundary memory corruption (integrity of unrelated kernel and process memory), with high confidentiality, integrity, and availability impact and changed scope. Private nonlinear fragments remain on the fast path; ESP output is unaffected because trailer append already cannot take the no-COW tailroom path on nonlinear skbs.

Why it matters to the business

A local low-privilege user can crash hosts, corrupt IPsec-protected or unrelated process data, or escalate privileges on any Linux system that processes ESP-in-UDP. Exploit maturity is weaponized, EPSS is about 0.94 and still rising, and named Dirty Frag activity targets this shared-fragment class—so unpatched kernels are an urgent operational risk even though the issue is not on CISA KEV and has no ransomware KEV flag. Linux’s ubiquity means large server, cloud, and appliance estates remain exposed until vendor kernels are updated. The flaw has been public for more than five months, increasing the chance of opportunistic local abuse.

How an attack unfolds

An attacker with a local unprivileged account on a host that handles ESP-in-UDP arranges for UDP datagrams to be built from spliced pipe pages so the kernel skb still references pages the attacker (or other processes) can access. Those fragments were not marked shared, so ESP input took the uncloned nonlinear fast path and decrypted ciphertext directly onto the shared pages. The in-place write is a memory-corruption primitive across privilege boundaries: controlled ciphertext and shared-page layout can smash kernel or process memory, causing panics, data tampering, or privilege escalation. Dirty Frag activity is associated with weaponizing this shared-fragment pattern; ESP output does not provide the same in-place write. No remote unauthenticated trigger is implied by the scoring (local, low privilege, no user interaction, changed scope).

How to fix it

Apply Linux kernel updates from your distribution or vendor that include the xfrm ESP shared-fragment fix (datagram splice marks SKBFL_SHARED_FRAG like TCP; ESP input calls skb_cow_data() when the flag is set). No canonical upstream version list was supplied with this record—use distro security advisories for the exact kernel package. Until patched, limit local untrusted users, disable or tightly control ESP-in-UDP (IPsec NAT-T) where it is not required, and restrict who can create UDP sockets and splice pages into the network stack. Do not rely on ESP output changes; this issue is input-path only. Reboot into the patched kernel so the running image matches the fixed package.

How to confirm the fix worked

Confirm the running kernel (uname -r and distro package changelog) includes the xfrm esp shared-frag change. In source or distro patches, verify IPv4/IPv6 datagram splice sets SKBFL_SHARED_FRAG and that ESP input falls back to skb_cow_data() when the flag is present, while private nonlinear frags still use the fast path. After upgrade, reboot and confirm the new image is active. Exposure checks: inventory hosts that load xfrm/ESP and accept ESP-in-UDP; treat any unpatched kernel with local users or containers as in-scope. Do not attempt to reproduce in-place decrypt on shared frags in production.

Typical attack path

1. Obtain local unprivileged access on a vulnerable Linux host that can send or receive ESP-in-UDP
2. Cause UDP datagrams to be assembled from spliced shared pipe pages so fragments are not privately owned by the skb
3. Induce ESP input processing on that packet so decryption runs in place on the shared fragments
4. Abuse the overwrite of shared pages to corrupt kernel or process memory
5. Convert the corruption into denial of service, integrity loss, or privilege escalation

How to detect it

This is in-kernel memory corruption, so evidence is mostly crashes and integrity failures rather than a reliable network signature. Search kernel logs (dmesg, journalctl -k, /var/log/kern.log, vmcore/kdump) for oops/panic/WARNING stacks through ESP or xfrm input around the time of suspected local abuse. Correlate with local UDP/ESP-in-UDP socket activity, splice/vmsplice-style page handoff, and sudden process or page-cache corruption. Look for Dirty Frag-associated local tooling or privilege-escalation follow-on. Absence of oopses does not prove non-exploitation; also review unexpected uid 0 transitions, container escapes, and IPsec policy or SA anomalies after local access. Network captures of ESP-in-UDP alone are not diagnostic of this in-place decrypt bug.

• esp_input
• xfrm_input
• xfrm4_rcv
• xfrm6_rcv
• net/xfrm/esp4.c
• net/xfrm/esp6.c
• skb_cow_data
• SKBFL_SHARED_FRAG
• Oops:
• kernel BUG at net/xfrm
• Call Trace:.*esp
• ESP-in-UDP

What your security team should do

• Patch and reboot Linux kernels to vendor builds that include the xfrm ESP SKBFL_SHARED_FRAG / skb_cow_data fix as the primary control
• Prioritize internet-facing, multi-tenant, container, and jump hosts that process IPsec NAT-T (ESP-in-UDP) and allow untrusted local users
• Until patched, reduce local attack surface: lock down unprivileged accounts, drop unnecessary CAP_NET_* and splice-friendly workloads, and disable unused ESP-in-UDP
• Hunt for Dirty Frag-style local memory-corruption activity and kernel oopses in xfrm/esp paths given weaponized maturity and ~0.94 EPSS
• Track distro advisories for exact package versions; this record has no fixed-version list and is not CISA KEV, but EPSS trend and age (162+ days) still warrant emergency patch SLAs