CVE-2026-93105
High · 7.8CVSS
7.8
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A mistake in the Linux kernel's handling of certain high-speed network data transfers can let someone who already has access to the computer crash it or take control.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Incorrectly calls skb_page_unref on managed frag pages (SKBFL_MANAGED_FRAG_REFS) inside esp_ssg_unref during out-of-place AEAD transforms or error paths, underflowing page reference counts and freeing pages that remain in use by zerocopy ubufs.
Why it matters to the business
Local privilege escalation or denial of service on Linux systems performing IPsec ESP processing with io_uring zero-copy sends; low public exploit activity reduces immediate external risk but still requires prompt kernel updates on affected hosts.
How an attack unfolds
A local attacker triggers ESP output transforms on an skb carrying managed frags attached via io_sg_from_iter from io_uring SEND_ZC registered buffers; the missing skb_zcopy_managed guard in esp_ssg_unref causes the reference underflow and subsequent use-after-free.
How to fix it
Apply the upstream kernel commit that adds the skb_zcopy_managed guard to esp_ssg_unref before any unref operations; rebuild and deploy the patched kernel on all systems performing IPsec ESP transforms.
How to confirm the fix worked
Inspect esp_ssg_unref in the kernel source to confirm the skb_zcopy_managed check precedes every skb_page_unref call; verify the same guard pattern already present in skb_release_data.
Typical attack path
- Obtain local unprivileged access on a Linux host using IPsec ESP
- Register buffers and issue io_uring SEND_ZC operations that produce SKBFL_MANAGED_FRAG_REFS skbs
- Force an ESP transform (req->src != req->dst) or hit an esp_output_tail error path
- Trigger the unguarded skb_page_unref calls to underflow page refcounts
- Reuse the freed page for arbitrary kernel memory corruption or crash
How to detect it
Search kernel logs for page refcount underflow warnings or use-after-free bugs originating from esp_ssg_unref or the ESP transform paths; correlate with processes using io_uring zero-copy sends over IPsec.
What your security team should do
- Patch kernels to the fixed version containing the skb_zcopy_managed guard as soon as packages are available
- Restrict unprivileged io_uring and IPsec configuration where feasible until patched
- Monitor for kernel oops or page refcount warnings in network paths
The record
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().
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|