Linux Kernel EUVD-2026-108744

Requires the mlx5e driver bound to an NVIDIA/Mellanox ConnectX interface running an AF_XDP socket in zero-copy mode on a striding RQ, plus a kernel XSK buffer allocation failure (-ENOMEM) during MPWQE refill so that actual_wq_head is not advanced and a later NAPI poll retries the same WQE over slots still marked releasable. Limiting factors that reduce realistic risk: this AF_XDP zero-copy striding-RQ setup is non-default and specific to mlx5 hardware, establishing the XSK socket requires privileged/CAP_NET_RAW-level setup, and the defect only manifests under memory exhaustion hitting the error/retry path (the reporter reproduced it only through forced fault injection across 1,575,262 allocation failures).

The input CVSS of 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N) overstates real-world risk and conflicts with the mechanism described. The description is a kernel memory-safety defect (double-free / use-after-free of XSK buffers via xsk_buff_free on stale pointers) that is only reachable when AF_XDP zero-copy is configured on a striding RQ on an mlx5e (NVIDIA/Mellanox ConnectX) NIC AND the kernel hits an XSK allocation failure (-ENOMEM) during MPWQE refill - i.e. it depends on local, privileged, non-default configuration plus memory pressure, not clean remote-unauthenticated reach. Supporting signals point the same way: EPSS is 0.22% (12th percentile), there is no CISA KEV listing, and no PoC or exploit reference appears in the input (no public exploit identified at time of analysis). The one escalating signal is the vuln.today 'act_now' decision label, which conflicts with the low EPSS and absent KEV/PoC; treat act_now as the governing urgency for patching, but understand the low EPSS/no-KEV combination indicates this is not a currently exploited, mass-scannable issue. Net: verify the attack vector with the vendor - CVSS claims AV:N/PR:N but the description implies locally-configured AF_XDP plus an -ENOMEM error path, so the true exploitability is far narrower than 9.8 suggests.

On a host using AF_XDP zero-copy on a striding receive queue of an mlx5e NIC, a local actor who can drive the interface into memory exhaustion causes XSK buffer allocation to fail with -ENOMEM during an MPWQE refill; the WQE is retried on a later NAPI poll and the already-released XSK buffers are freed a second time through stale pointers after they have been reallocated from the pool. The resulting kernel double-free/use-after-free can corrupt kernel memory, typically leading to a crash and potentially further corruption. No public exploit was identified at time of analysis; triggering depends on forcing the specific allocation-failure retry path (the vendor reproduced it only via fault injection).