Linux kernel CVE-2026-99079

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.

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.

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.