CVE-2026-93105 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
esp: do not unref managed frag pages in esp_ssg_unref()
esp_ssg_unref() releases the page references held on the source scatterlist after the AEAD operation completes. It calls skb_page_unref() on every frag page for an out-of-place transform (req->src != req->dst), and in the error path of esp_output_tail() (already_unref == true) on the request's own scatterlist.
This is wrong when the skb carries managed frags (SKBFL_MANAGED_FRAG_REFS). Managed frags are owned by a zerocopy ubuf and the skb does not hold a per-frag page reference; io_uring SEND_ZC with a registered buffer attaches the bvec pages this way via io_sg_from_iter(). The rest of the stack honours this invariant: skb_release_data() skips the per-frag unref when SKBFL_MANAGED_FRAG_REFS is set, and skb_zcopy_managed() is the guard used at the other unref sites.
esp_ssg_unref() is missing that guard, so for a managed-frag skb it drops a page reference the skb never acquired. This can underflow the page reference count and free a page that is still in use.
Guard the function with skb_zcopy_managed() so both unref paths are skipped for managed-frag skbs, matching skb_release_data().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel networking subsystem contains a critical memory management flaw within the IPsec ESP (Encapsulating Security Payload) implementation that can lead to use-after-free vulnerabilities and system instability. The vulnerability resides in the esp_ssg_unref function, which is responsible for releasing page references held on source scatterlist pages after an AEAD operation completes. Under normal circumstances, this function correctly handles out-of-place transforms where the source and destination buffers differ by calling skb_page_unref on each fragment page. It also manages error paths within esp_output_tail when a request has already been unrefed. However, the implementation fails to account for a specific class of network buffer descriptors known as managed fragments, identified by the SKBFL_MANAGED_FRAG_REFS flag. This oversight creates a discrepancy in reference counting logic that compromises memory safety during high-throughput or zero-copy operations.
Managed frags are associated with zerocopy user buffers, typically utilized through io_uring SEND_ZC commands where registered buffers attach bvec pages directly to the socket buffer without duplicating data. In these scenarios, the kernel does not acquire per-frag page references because ownership remains with the underlying ubuf structure. The rest of the networking stack correctly respects this invariant by checking for SKBFL_MANAGED_FRAG_REFS before attempting to release references. Specifically, functions like skb_release_data and other unref sites utilize the skb_zcopy_managed guard to skip reference counting operations when managed fragments are present. This ensures that pages owned by user-space buffers are not prematurely freed or corrupted by kernel-side refcount manipulation.
The absence of this guard in esp_ssg_unref results in a dangerous logic error where the function attempts to drop page references for skbs carrying managed frags, despite never having acquired them. When skb_page_unref is invoked on these pages, it decrements reference counts that were not incremented during buffer setup. This leads to an underflow of the page reference count, potentially reducing it below zero or causing incorrect state tracking within the kernel memory manager. Consequently, a page that remains actively in use by user-space applications may be incorrectly marked as free and returned to the buddy allocator. If this freed page is subsequently reallocated for other purposes while still being referenced by an active zerocopy operation, it results in a classic use-after-free condition.
The operational impact of this vulnerability extends beyond simple memory corruption. An attacker who can trigger zero-copy IPsec operations with managed fragments may exploit the reference count underflow to achieve arbitrary code execution or cause a denial of service through kernel panic. The issue is particularly relevant for systems utilizing io_uring for high-performance network I/O, as these workloads are more likely to employ zerocopy mechanisms that expose this specific code path. The lack of proper synchronization between the IPsec output processing and the managed fragment lifecycle creates a window where memory safety guarantees are violated, undermining the integrity of both kernel and user-space data structures.
Mitigation strategies must address both immediate patching and long-term architectural improvements. The primary remediation involves applying the upstream Linux kernel fix that adds an skb_zcopy_managed check to esp_ssg_unref. This guard ensures that for skbs with managed fragments, neither unref path is executed, thereby preserving the correct reference counts and preventing premature page reclamation. System administrators should prioritize updating their kernels to versions containing this patch, particularly those running services that rely on io_uring or high-throughput IPsec tunnels. Additionally, developers integrating zero-copy networking stacks should audit similar code paths for consistency in handling managed fragments to prevent recurrence of such invariant violations across the network stack.
From a vulnerability classification perspective, this issue aligns with CWE-125, Out-of-bounds Read, and CWE-416, Use After Free, due to the manipulation of reference counts leading to invalid memory access scenarios. In terms of attack vectors, it relates to ATT&CK technique T1078, Valid Accounts, if exploited via authenticated network connections, though more accurately it represents a local privilege escalation or remote code execution vector depending on whether untrusted input can trigger the specific IPsec processing path with managed fragments. The root cause is categorized under CWE-691, Insufficient Control Flow Management, as the function fails to properly branch based on buffer ownership type before performing destructive operations. Ensuring strict adherence to reference counting invariants across all network buffer handling functions is essential for maintaining system stability and security integrity in modern Linux environments.