Skip to main content

Linux Kernel CVE-2026-93105

| EUVDEUVD-2026-82213 HIGH
2026-09-17 Linux GHSA-m483-33mw-4p7w
7.8
CVSS 3.1 · Vendor: Linux
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Local access to host with IPsec ESP output configured
  2. Delivery
    Issue io_uring SEND_ZC with registered managed-frag buffer
  3. Exploit
    ESP out-of-place/error path calls esp_ssg_unref without managed guard
  4. Execution
    Page refcount underflow frees in-use page
  5. Impact
    Kernel memory corruption and crash (DoS)

Vulnerability Assessment

Exploitation Conditions

Requires local code execution on a kernel where IPsec ESP output is configured for traffic, AND the sending process uses io_uring SEND_ZC with a registered/managed-frag (SKBFL_MANAGED_FRAG_REFS) buffer whose pages traverse the ESP transform. Triggered specifically in the out-of-place transform case (req->src != req->dst) or the esp_output_tail error path (already_unref). Limiting factors: not reachable against default hosts without IPsec ESP in use; requires the io_uring zerocopy send path rather than ordinary sockets; no remote or unauthenticated vector; impact is kernel memory corruption/crash rather than data theft.

Impact

The vendor CVSS of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) overstates real-world risk. The vector's local, low-complexity, low-privilege framing is defensible for the access requirement, but AC:L understates the preconditions: the flaw only triggers when the host is configured for IPsec ESP output AND the transmitting local process uses io_uring SEND_ZC with a registered (managed-frag) buffer that routes through the ESP transform - a specific software path, not a default one. The C:H/I:H triad is misleading: this is a page reference-count underflow that frees a page still in use (a use-after-free / memory-corruption primitive), which is overwhelmingly a crash/DoS and potential corruption issue, not an information-disclosure or integrity-of-data flaw. No EPSS score, no CISA KEV listing, and no public exploit are present in the input, so there is no signal of active or automated exploitation. SSVC-style read: exploitation=none observed, automatable=no (requires a crafted local zerocopy send over an IPsec-configured path), technical impact=partial-to-total (kernel memory corruption). Net: a legitimate kernel memory-safety bug worth patching on IPsec+io_uring hosts, but a moderate priority rather than the high-7.8 the vendor score implies. Note the conflict to verify: the 'Information Disclosure' tag contradicts the actual UAF/DoS impact, and CWE is listed as N/A despite a clear CWE-416/415-class defect.

Exploit ScenarioDerived

A local user on a host configured for IPsec ESP output sends data through an io_uring SEND_ZC operation backed by a registered (bvec/managed-frag) buffer. After the AEAD transform completes, esp_ssg_unref() drops a page reference the skb never acquired, underflowing the page refcount and freeing a page still in active use, corrupting kernel memory and typically crashing the system. No public exploit code is identified at time of analysis; the path requires both IPsec configuration and the io_uring zerocopy send code path.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 18, 2026

A page reference-count underflow in the Linux kernel's IPsec ESP output path (esp_ssg_unref()) can free a page that is still in use, because the function omits the skb_zcopy_managed() guard when releasing per-frag references on a scatterlist. The bug is reachable only by a local, already-privileged-within-their-context process (CVSS PR:L) that sends data through io_uring SEND_ZC with a registered/managed-frag buffer whose pages traverse an ESP transform while IPsec ESP output is configured; our assessment rates it AV:L/AC:H with C:N/I:L/A:H, notably lower risk than the vendor's 7.8 score, since it requires a specific combination of io_uring zerocopy, managed frags (SKBFL_MANAGED_FRAG_REFS), and an out-of-place AEAD transform (req->src != req->dst) or the esp_output_tail() error path. No public exploit code has been identified and the flaw is not confirmed actively exploited (CISA KEV), though vendor patches exist and the underlying defect has been present since at least Linux 4.11 per EUVD.

RemediationAI

Apply the vendor-released kernel fix: the guard is present in Linux 7.2.6 and 7.3-rc1, delivered via mainline commit cac2661c53f35cbe651bef9b07026a5a05ab8ce0 and stable commits 21697720ff43b8dfa25b8e8d9ca7f56f4597fc80 and 26b6b14c7a0368e317a1e9fb5144ebe6f8d495cf; upgrading to a kernel release containing any of these commits resolves the issue, and distributors should be followed for their own backported builds (see https://git.kernel.org/stable/c/21697720ff43b8dfa25b8e8d9ca7f56f4597fc80 and https://nvd.nist.gov/vuln/detail/CVE-2026-93105). If an immediate upgrade is not possible, the practical compensating control is to eliminate the trigger precondition rather than the bug: avoid using io_uring SEND_ZC with registered buffers on hosts where IPsec ESP output is active, since ordinary send/sendmsg paths with page-backed skbs do not set SKBFL_MANAGED_FRAG_REFS and therefore do not enter the faulty branch - the trade-off is a measurable loss of zero-copy transmit performance and possibly the loss of registered-buffer throughput benefits. Disabling or unloading ESP output (for example by removing IPsec policy that forces ESP encapsulation, or blocking ESP/4500 traffic) also removes reachability, at the cost of losing the confidentiality/integrity services that IPsec was providing, so it is only suitable for hosts where those protections are dispensable or can be reimplemented at another layer. Because exploitation requires a local process already executing code on the system, standard host hardening (restricting access to io_uring via seccomp or sysctl knob /proc/sys/kernel/io_uring_disabled where available) reduces exposure, with the side effect of breaking applications that legitimately depend on io_uring, including SEND_ZC-based network servers.

Affected VersionsENISA

Linux patch: 7.2.6
Linux cac2661c53f35cbe651bef9b07026a5a05ab8ce0 <21697720ff43b8dfa25b8e8d9ca7f56f4597fc80
Linux patch: 0
Linux cac2661c53f35cbe651bef9b07026a5a05ab8ce0 <26b6b14c7a0368e317a1e9fb5144ebe6f8d495cf
Linux 4.11
Linux patch: 7.3-rc1

Affected Packages

euvd linux no fix

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

The flaw is a reference-counting defect in the kernel's fast-path handling of zero-copy skb fragments. esp_ssg_unref() runs after an AEAD operation in the ESP (IPsec) transmit path and is responsible for releasing page references held on the source scatterlist, either for the out-of-place case where req->src != req->dst, or in the error path of esp_output_tail() when already_unref is true. The rest of the networking stack respects an invariant for skbs carrying managed frags: when SKBFL_MANAGED_FRAG_REFS is set, the frag pages are owned by a zerocopy ubuf and the skb holds no per-frag page reference, so skb_release_data() skips the per-frag unref and other unref sites use skb_zcopy_managed() as a guard. io_uring's SEND_ZC path attaches registered-buffer bvec pages this exact way via io_sg_from_iter(). esp_ssg_unref() lacks that guard, so it calls skb_page_unref() on pages it never pinned, underflowing the page refcount and enabling premature page freeing and subsequent use-after-free of live kernel memory. CWE is not supplied in the source data; the defect class is improper/inconsistent reference counting leading to a use-after-free. Affected CPE identifiers are cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:* with the vulnerable construct introduced as early as Linux 4.11 according to EUVD.

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

Vendor (Linux) PRIMARY 7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI 5.3 MEDIUM

Local vector needing IPsec ESP plus io_uring managed-frag zerocopy makes AC:H and PR:L; impact is kernel memory corruption/crash (A:H, I:L) with no disclosure (C:N).

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H
4.0 AV:L/AC:H/AT:N/PR:L/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N
Red Hat 7.0 MEDIUM

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

4
CVSS changed
Sep 18, 2026 - 18:22 NVD
7.8 (HIGH)
Patch available
Sep 17, 2026 - 17:19 EUVD
CVE Published
Sep 17, 2026 - 16:11 cve.org
HIGH 7.8
CVE Published
Sep 17, 2026 - 16:11 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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().

Executive ViewAI

Why It Matters

A high-severity memory-safety issue in the Linux kernel's IPsec ESP output path can let a local user with existing privileges corrupt kernel memory, causing crashes or potentially further privilege escalation on systems that combine IPsec ESP output with io_uring zerocopy send using managed-frag buffers. Organizations running affected Linux kernels in multi-tenant, edge, VPN, or security-sensitive environments should treat this as a priority patch-management issue because the defect can affect system availability and integrity, although no public exploit identified at time of analysis. Vendor patches are available, so leadership should drive rapid kernel updates and verify exposure.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 91% exploitable
Prevalence
Low
Linux kernel is ubiquitous but esp+io_uring zerocopy over IPsec is a niche path
Data Quality
5 sources
Confidence: Medium

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.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Defer
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact
High

Priority Score

39
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +39
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Vendor StatusVendor

SUSE

Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy