CVE-2026-43284: Fix for in‑place decryption on shared skb fragments in Linux’s ESP path

A recent Linux kernel change addresses a flaw in the IPsec/ESP receive path that could decrypt network data “in place” over memory the kernel did not privately own. The issue is tracked as CVE-2026-43284 and is fixed upstream. While some third‑party posts speculate on impact and exploitation, the kernel-side evidence focuses on correcting memory ownership handling in a specific fast path.

What we know

The kernel patch titled “xfrm: esp: avoid in-place decrypt on shared skb frags” explains the problem and the fix. When MSG_SPLICE_PAGES attaches pages from a pipe directly to a socket buffer (skb), TCP marks those skbs with the SKBFL_SHARED_FRAG flag so later code that might modify data can first take a private copy. The IPv4/IPv6 datagram append paths, however, did not set this flag when splicing pages into UDP skbs.

That omission made an ESP-in-UDP packet built from shared pipe pages appear to be a normal, privately owned skb. The ESP input path, seeing an uncloned skb without a frag_list, took a no-copy fast path and decrypted directly over the attached pages—pages that were not privately owned by the skb.

The fix does two things:

• Marks IPv4/IPv6 datagram splice fragments with SKBFL_SHARED_FRAG, aligning UDP behavior with TCP.
• Makes ESP input fall back to skb_cow_data() when the shared-frag flag is present, ensuring decryption happens on private memory.

According to the commit, ESP output paths are unaffected because the specific no-copy tail-append path is not reachable for nonlinear skbs.

Kernel reference: https://git.kernel.org/stable/c/50ed1e7873100f77abad20fd31c51029bc49cd03

Why it matters

Network fast paths rely on strict memory ownership rules. When the kernel treats shared pages as private and modifies them in place, it risks corrupting data outside the skb’s control. Even without a published impact analysis, correcting this kind of ownership mistake is important for system integrity—especially in environments using ESP over UDP (for example, NAT traversal) and zero‑copy mechanisms like splice.

Practical next steps (based on available evidence)

• Apply Linux kernel updates that include the referenced fix when they become available for your distribution.
• Monitor your distribution’s advisories for CVE-2026-43284 and schedule reboots as needed to load the updated kernel.
• If your environment relies on IPsec ESP over UDP or applications that splice pages into UDP sockets, prioritize testing and deployment of the kernel update.

What’s still unclear

• Affected kernel version ranges are not stated in the kernel commit linked above.
• The commit does not describe observed exploitation, privilege impact, or a CVSS score.
• A third‑party blog has referred to “Dirty Frag” and discussed exploitation claims and chaining with other CVEs. Those assertions are not confirmed by the kernel commit or NVD entry referenced here and should be treated as unverified in this context.

Bottom line

CVE-2026-43284 fixes a memory ownership flaw in the ESP receive path triggered by UDP datagram splicing. The upstream change is straightforward—mark shared fragments correctly and force copy‑on‑write before decryption. Until distributions publish full advisories, the most practical step is to track kernel updates and plan timely rollouts, particularly for systems that use ESP over UDP and zero‑copy networking features.

Alex Mira

Alex Mira is a fictitious AI-assisted author created for the Toolslib blog. Designed to support cybersecurity education, Alex writes about malware trends, software utilities, privacy practices, Windows internals, and practical defensive workflows. Articles published under Alex’s name are generated or assisted by AI and reviewed according to Toolslib’s editorial standards before publication.