Skip to main content

Linux kernel EUVDEUVD-2026-108745

| CVE-2026-99079 CRITICAL
2026-10-23 Linux GHSA-7w5x-75mg-qr73
9.8
CVSS 3.1 · Vendor: Linux
View

Attack ChainAIDerived

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

  1. Recon
    Configure/abuse AF_XDP zero-copy on mlx5e RQ
  2. Delivery
    Flood small UDP to fill RX ring
  3. Exploit
    XSK core frees buffer on redirect failure
  4. Install
    Partial batched refill leaves stale WQE pointer
  5. C2
    Refill retry double-frees live buffer
  6. Execute
    Same UMEM frame published twice
  7. Impact
    Cross-frame data leak/corruption

Vulnerability Assessment

Exploitation Conditions

Exploitation is confined to hosts running the mlx5e driver (Mellanox/NVIDIA ConnectX-class NICs) with an AF_XDP (XSK) zero-copy socket attached to a legacy cyclic RQ, and an XDP program performing redirects to that socket. The specific trigger is an AF_XDP RX ring that fills up (so the XSK core frees the buffer) followed by a batched refill of the cyclic RQ that succeeds only partially, leaving a WQE with a stale buffer pointer that a later refill retry frees again. Limiting factors that sharply reduce real-world exposure: the affected feature is not enabled by default (requires an AF_XDP zero-copy application and the legacy cyclic-RQ mode), requires the specific Mellanox hardware/driver, and requires sustained high-rate traffic to drive the ring-full/partial-refill condition. The failure is silent (no warning or splat), so it is primarily a data-integrity/disclosure risk within the socket's own UMEM rather than a system crash.

Impact

The raw signals conflict sharply and must not be read at face value. The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H, score 9.8) describes a remote, unauthenticated, full-impact flaw, but the description describes something much narrower: a stale/double-freed AF_XDP UMEM buffer in the mlx5e driver's legacy cyclic RQ zero-copy path, triggered when an XDP-redirect to an AF_XDP socket hits a full RX ring and a subsequent batched refill only partially succeeds. That is a memory-ownership defect reachable only on hosts that have already configured AF_XDP zero-copy on a Mellanox mlx5 NIC in legacy cyclic-RQ mode - not a property of a default Linux install, so the AV:N/PR:N/C:H/I:H/A:H rating overstates real-world reach (CVSS indicates network/unauthenticated full impact, but the description implies a locally configured, privileged datapath - verify scope before treating as remote RCE). The exploitation-probability signals are consistently low-to-moderate: EPSS is 0.21% (10th percentile), the CVE is NOT in CISA KEV (no confirmed active exploitation), and no public exploit or PoC reference is supplied. The only elevating signal is the vendor/aggregator Decision label of act_now, which conflicts with the low EPSS and absent KEV - consistent with a high-CVSS kernel fix that should be patched promptly through normal stable-kernel updates rather than treated as an actively exploited emergency. Net: real but not widespread - a genuine memory-safety bug worth patching on affected mlx5e/AF_XDP fleets, not a drop-everything internet-facing threat.

Exploit ScenarioDerived

On a host running an AF_XDP zero-copy application bound to a Mellanox mlx5e interface in legacy cyclic-RQ mode, a flood of small (e.g. 64-byte) UDP packets fills the AF_XDP RX ring so XDP redirects fail and the core frees buffers; a partially-successful batched refill then leaves a WQE pointing at a buffer that has been reassigned, and a later refill frees the live buffer through the stale pointer, publishing the same UMEM frame twice. The result is silent frame double-publication and cross-frame data exposure/corruption within the socket's UMEM, with no kernel warning or crash. No public exploit or PoC reference is identified at time of analysis; the original reporter demonstrated the fault only with a standalone libxsk reproducer under heavy traffic.

Act Now Prioritize within 24-48h. Why: CRITICAL severity.
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 – Oct 24, 2026

Stale XSK buffer bookkeeping in the Linux kernel's mlx5e driver lets a buffered WQE pointer be freed a second time and the same UMEM frame published twice on AF_XDP zero-copy sockets, producing silent data-integrity and limited information-disclosure effects within the socket's own memory region rather than a crash. Only hosts using Mellanox/NVIDIA ConnectX-class hardware, an XDP program redirecting to an AF_XDP zero-copy socket, and the legacy cyclic RQ mode are affected, and the condition requires an RX ring that fills under sustained high-rate traffic followed by a partially successful batched refill; the published CVE record carries a 9.8 network-vector score, while the locally assessed vector (AV:L/AC:H/PR:L/UI:N/C:L/I:L/A:N) reflects that the feature is off by default and hardware-gated. No public exploit or PoC has been identified at time of analysis and EPSS is 0.21% (10th percentile), so there is no confirmed active exploitation despite the act_now triage label.

RemediationAI

Vendor-released patch: Linux 6.6.160, 6.12.113, 6.18.57 and 7.2.11 (7.3 also carries the fix); apply the stable update matching your branch or cherry-pick the upstream commit listed at https://git.kernel.org/stable/c/32bbb870078d467479965c21bbc4960c57eea208 (and the sibling stable commits 34d1db2b18e1c1d189e34dd51923e031815f88e3, 639522e5056cade578a324acfa993ec6c9f7f5dc, 655f47477054d19de3b138840be229a1a4490d0c, e01620844c5c88b6fcf819d171df8e3976a0e76f for other branches). Because the defect is silent it will not surface in dmesg, so exposure must be determined from configuration rather than from log evidence. Where updating must be staged, the affected path can be avoided by not running AF_XDP zero-copy applications against mlx5e legacy cyclic RQs, or by removing XDP redirect rules that target XSK sockets on those interfaces - the trade-off is loss of the zero-copy redirect feature and any performance or functionality that depends on it, and the ring-full/partial-refill trigger is only reliably reached under sustained high packet rates, so low-rate management traffic is not a substitute for patching. Disabling AF_XDP zero-copy entirely on the affected NICs is the only configuration-level control the upstream commit description supports; no other workaround is documented, and the vendor fix is the complete remedy.

Affected VersionsENISA

Linux 6.4
Linux 3f93f82988bc6b4104314bf9aa485d47fbb7e241 <639522e5056cade578a324acfa993ec6c9f7f5dc
Linux patch: 6.12.113
Linux patch: 7.2.11
Linux patch: 6.18.57
Linux 3f93f82988bc6b4104314bf9aa485d47fbb7e241 <e01620844c5c88b6fcf819d171df8e3976a0e76f
Linux patch: 0
Linux 3f93f82988bc6b4104314bf9aa485d47fbb7e241 <655f47477054d19de3b138840be229a1a4490d0c
Linux patch: 7.3
Linux 3f93f82988bc6b4104314bf9aa485d47fbb7e241 <34d1db2b18e1c1d189e34dd51923e031815f88e3
Linux patch: 6.6.160
Linux 3f93f82988bc6b4104314bf9aa485d47fbb7e241 <32bbb870078d467479965c21bbc4960c57eea208

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 lives in the net/mlx5e Ethernet driver path that services AF_XDP (XSK) zero-copy sockets. With zero-copy, the driver hands NIC receive buffers from a user-space UMEM region directly to the hardware via WQEs (work queue entries) on a receive queue, and on the legacy cyclic RQ the driver periodically refills consumed WQEs in batches. When an XDP redirect to an AF_XDP socket fails because the socket's RX ring is full, the XSK core frees the buffer. During the following batched refill, mlx5e also released the WQE's XSK buffer before allocating a replacement; if allocation succeeded only partially, WQEs left without a replacement kept their old buffer pointer. Because the freed frame could be handed to another WQE in the meantime, a later refill retry frees the now-live buffer through that stale pointer and the same UMEM frame is published twice, yielding ownership/double-publication errors. The fix marks the WQE as released immediately after the driver-side free, and the flag is cleared again when a replacement is assigned, so retries never act on stale pointers. No CWE class was assigned in the supplied data; the behavior is a buffer-lifetime/ownership defect, not a memory-safety crash path, and the upstream commit message notes the failure is silent with no kernel warning or splat. The reproducer in the commit is a standalone legacy cyclic-RQ zero-copy libxsk program driving 64-byte UDP at 12 Mpps, which produced 4,542 ring-full events and 64 ownership/double-publication errors on unpatched kernels versus none after the change.

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 9.8 CRITICAL
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vuln.today AI 3.6 LOW

Reachable only via a locally configured, privileged AF_XDP zero-copy mlx5e datapath (PR:L, AV:L) under a specific ring-full/partial-refill condition (AC:H); impact is in-UMEM frame leak/corruption (C:L/I:L), silent with no crash (A:N).

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

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

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

Lifecycle Timeline

4
CVSS changed
Oct 24, 2026 - 14:22 NVD
9.8 (CRITICAL)
Patch available
Oct 23, 2026 - 13:17 EUVD
CVE Published
Oct 23, 2026 - 12:23 cve.org
UNKNOWN (no severity yet)
CVE Published
Oct 23, 2026 - 12:23 cve.org
CRITICAL 9.8

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Prevent stale XSK buffer release on refill retry

When an XDP redirect to an AF_XDP socket fails because its RX ring is full, the XSK core frees the buffer. During the subsequent batched refill of a legacy cyclic RQ, mlx5e also releases the WQE's XSK buffer before allocating a replacement. If that refill succeeds only partially, a WQE left without a replacement retains its old buffer pointer.

The buffer can meanwhile be allocated to another WQE. A later refill retry can then free the live buffer through the stale pointer and publish the same UMEM frame twice.

Mark the WQE as released immediately after the driver-side free. The flag is already cleared when a replacement buffer is assigned, so refill retries no longer release stale pointers.

The failure is silent and produces no kernel warning or splat. A standalone legacy cyclic-RQ zero-copy libxsk reproducer, using 64-byte UDP traffic offered at 12 Mpps, detected it: stock stopped after 2,854,914 packets in 4.094 seconds, with 4,542 xdp_rx_ring_full events and 64 ownership/double-publication errors. With this change it processed 356,904,225 packets in 30 seconds despite 571,405 xdp_rx_ring_full events, with no ownership or data errors.

Executive ViewAI

Why It Matters

A critical vulnerability in the Linux kernel's mlx5e driver for NVIDIA/Mellanox ConnectX network hardware could allow a local attacker with low privileges to cause silent data corruption and limited information disclosure under specific configurations. Only organizations using this hardware with AF_XDP zero-copy sockets and legacy cyclic RQ mode are at risk, which is off by default, limiting real-world exposure. Leadership should prioritize patching affected systems to mitigate potential integrity issues, though no active exploitation has been observed.

Business Impact: Medium
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 90% exploitable
Prevalence
Medium
Linux is ubiquitous, but the vulnerable path needs mlx5 NICs with AF_XDP zero-copy
Data Quality
4 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 CRITICAL
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
CRITICAL severity
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
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
Yes
Human Impact
Medium

Priority Score

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

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

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