EUVD-2026-93353
GHSA-jw2q-x793-gp2m
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain local unprivileged account
-
DeliveryConfigure/use IPsec ESP transform with MSG_ZEROCOPY send
-
ExploitForce out-of-place ESP output path
-
ExecutionTrigger unbalanced refcount on pinned frags
-
PersistUse-after-free / page leak in kernel
-
ImpactKernel crash or memory corruption for escalation
Vulnerability Assessment
| Exploitation Conditions | Requires a Linux host using IPsec ESP where the out-of-place output path is taken (esp->inplace == false) AND the skb carries zerocopy managed frags (SKBFL_MANAGED_FRAG_REFS), i.e. a local sender using MSG_ZEROCOPY whose payload pages are ubuf-owned/GUP-pinned. Limiting factors: the attacker must have a local account and the ability to send over an ESP transform (PR:L, AV:L), and both the ESP out-of-place branch and zerocopy frag ownership must coincide - on hosts without IPsec ESP configured, or without zerocopy sends on that path, the frag-mutation code is not reached. No remote/network-facing exploitation and no cross-host reach. |
| Impact | Signals are broadly consistent toward a moderate, not urgent, priority. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.8) correctly reflects a local, low-privilege kernel memory-safety flaw: a use-after-free of GUP-pinned zerocopy pages plus a page-refcount leak on the ESP out-of-place output path. The attack vector is LOCAL, not network - despite this being an IPsec/ESP networking bug, triggering it requires a local sender emitting MSG_ZEROCOPY traffic through an ESP transform, so it is not remotely reachable by an off-host attacker. EPSS is low (0.17%, 6th percentile) and the CVE is NOT in CISA KEV, with no public exploit identified, which aligns: this is a hard-to-weaponize race/refcount bug gated on a specific kernel configuration. The main real-world risk is local privilege escalation or kernel crash on hosts that both run IPsec ESP and allow untrusted local users to drive zerocopy sends - a narrow combination. Note one tension to verify: the input Tags label this 'Information Disclosure', but the described primary impact is use-after-free/memory corruption and a page-rate memory leak (DoS), not confidentiality disclosure; treat the tag as imprecise. Overall: a legitimate high-CVSS local kernel bug worth patching in the normal stable-kernel cadence, but not an emergency given low exploitation probability, no KEV, no POC, and local-only reach. |
| Exploit ScenarioDerived | A local, low-privileged user on a Linux host configured with IPsec ESP sends traffic over a socket using MSG_ZEROCOPY so the skb carries managed (ubuf-owned) frags, forcing ESP down the out-of-place output path. ESP mutates the frag array without downgrading the managed frags, dropping references on still-pinned zerocopy pages (use-after-free) or leaking the destination page, which can crash the kernel or corrupt memory for potential privilege escalation. No public exploit or POC has been identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 07, 2026
Use-after-free of GUP-pinned zerocopy page buffers in the Linux kernel's IPsec ESP out-of-place output path lets a local, authenticated user (CVSS:3.1/AV:L/AC:L/PR:L/UI:N) who can send MSG_ZEROCOPY traffic over an ESP transform corrupt memory, potentially achieving privilege escalation (C:H/I:H/A:H), while the same code path simultaneously leaks an x->xfrag page per packet. Exploitation requires a host with IPsec ESP configured where esp->inplace == false and where the transmitted skb carries SKBFL_MANAGED_FRAG_REFS, so hosts without ESP or without zerocopy sends on that path do not reach the vulnerable frag mutation. No public exploit has been identified at time of analysis, the issue is not in CISA KEV, and the EPSS score is low (0.17%, 6th percentile), consistent with a moderate-priority local issue; vendor-released patches exist in 6.1.189, 6.6.158, 6.12.112, 6.18.54, 7.2.8, and 7.3-rc4.
RemediationAI
Apply the vendor-released Linux kernel patches: upgrade to 6.1.189, 6.6.158, 6.12.112, 6.18.54, 7.2.8, or 7.3-rc4 (or later), which backport the fix that calls skb_zcopy_downgrade_managed() before ESP mutates the frag array; downstream distributions should track the corresponding stable commit links (e.g. https://git.kernel.org/stable/c/2359264f377cdbdef2d95868cc8fb572949e48d3, .../69a768c12398cada8528080332c822623fa7064d, and the other listed stable hashes). Since exploitation requires a local account able to send over an ESP transform, the practical risk is limited to multi-user hosts that combine IPsec ESP with zerocopy-capable senders, but patching is the only complete fix because the reference-counting imbalance is internal to the kernel and cannot be configured away from user space with certainty. Until patching is possible, reduce exposure by not running IPsec ESP in a configuration that takes the out-of-place output path on hosts with untrusted local users, and by disabling or avoiding application use of MSG_ZEROCOPY on traffic that traverses ESP (for example via application configuration or by fronting the sender with a proxy that performs normal copies); the trade-off is lower transmit throughput and higher CPU/memory-bandwidth cost on those flows. Restricting local account access to hosts with ESP tunnels and monitoring for kernel memory corruption or unreclaimable page growth from the x->xfrag leak provide only partial compensating visibility, since a successful use-after-free may leave no log signature. Do not rely on network-perimeter controls - this defect is reachable only from local senders and is not remotely triggerable.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
IPsec ESP's out-of-place output path (esp->inplace == false) rewrites the skb fragment array: esp_output_head() appends a trailer frag and esp_output_tail() replaces the frags with a destination page, both obtained via get_page(). When the skb instead carries zerocopy managed frags (SKBFL_MANAGED_FRAG_REFS), the payload frags are owned by the ubuf/GUP pin and must not be individually referenced or unreferenced - the managed-frag contract assumes skb_release_data() will skip per-frag unrefs. ESP violated that invariant in two directions: esp_ssg_unref() walks the source scatterlist and drops a page reference for every entry, including the ubuf-owned payload frags, pushing their refcount below the GUP pin bias while the pages remain pinned, which is a use-after-free of the zerocopy pages; and esp_output_tail() installs its destination page as frag 0 with get_page() but leaves SKBFL_MANAGED_FRAG_REFS set, so skb_release_data() takes the skip_unref branch and never releases that reference, leaking the x->xfrag page at packet (alloc/free) rate. The upstream fix follows the pattern already used by every other frag-mutating site - __ip_append_data(), __ip6_append_data(), and tcp_sendmsg_locked() - by calling skb_zcopy_downgrade_managed() before ESP touches the frag array, which takes a real reference on each existing frag and clears the managed flag, so the per-frag unref in esp_ssg_unref() and the release in skb_release_data() are balanced and no mixed-ownership frag array is left behind. No CWE was supplied; the root cause class is improper reference counting / use-after-free combined with a resource leak. The CPE data (cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:*) covers the Linux kernel broadly, with the vulnerable range beginning at commit 753f1ca4e1e50248a1b760c9774d6d6b354562cc.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local low-priv sender drives the ESP zerocopy path (AV:L/PR:L); the refcount imbalance is reliably triggerable (AC:L) and a kernel UAF yields full C/I/A impact.
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
Lifecycle Timeline
4DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
esp: downgrade zerocopy managed frags before mutating skb frags
On the out-of-place output path (esp->inplace == false) ESP rewrites the skb frag array: esp_output_head() appends a trailer frag and esp_output_tail() replaces the frags with a destination page, both referenced with get_page().
When the skb carries zerocopy managed frags (SKBFL_MANAGED_FRAG_REFS) the payload frags are owned by the ubuf and must not be referenced or unreferenced individually, but ESP mutates the frag array without ever downgrading the skb. This breaks the managed-frag invariant two ways:
- esp_ssg_unref() walks the source scatterlist and drops a page
reference for every frag, including the ubuf-owned payload frags, pushing their refcount below the GUP pin bias while the pages are still pinned, i.e. a use-after-free of the zerocopy pages;
- esp_output_tail() installs its destination page as frag 0 with
get_page() but leaves SKBFL_MANAGED_FRAG_REFS set, so skb_release_data() takes the skip_unref branch and never drops that reference, leaking the x->xfrag page at packet rate.
Fix this the way every other frag-mutating site does (__ip_append_data(), __ip6_append_data(), tcp_sendmsg_locked()) and call skb_zcopy_downgrade_managed() before ESP touches the frag array: it takes a real reference on each existing frag and clears SKBFL_MANAGED_FRAG_REFS, so the per-frag unref in esp_ssg_unref() and the frag release in skb_release_data() are both balanced and no mixed-ownership frag array is left behind.
Executive ViewAI
A high-severity vulnerability (CVE-2026-98368) in the Linux kernel allows a local authenticated user to escalate privileges on systems configured with IPsec ESP and zerocopy network traffic, potentially leading to full system compromise. Organizations running affected Linux versions in such configurations face risk of unauthorized access to sensitive data and disruption of critical services, though no public exploit has been identified and the EPSS score is low. Leadership should prioritize patching to mitigate potential insider threats or post-compromise escalation.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB