CVE-2026-99078

What it actually does

Use-after-free in mlx5e AF_XDP striding RQ path: mlx5e_free_rx_mpwqe can call xsk_buff_free twice on the same buffers when mlx5e_xsk_alloc_rx_mpwqe hits -ENOMEM, because the skip_release_bitmap is not fully set on the error path, leaving stale pointers that are dereferenced on the next NAPI retry of the same MPWQE.

Why it matters to the business

Systems using mlx5e NICs with AF_XDP zero-copy may experience kernel crashes, memory corruption, or local privilege escalation; the bug affects high-performance networking workloads and was published only two days ago, requiring rapid patching on any Linux deployment that carries the affected driver code.

How an attack unfolds

An attacker with the ability to open an AF_XDP socket on an mlx5e device forces repeated allocation failures (via memory pressure or fault injection) during MPWQE refill; the resulting stale bitmap entries cause xsk_buff_free to be invoked again after the buffers have been returned to the XSK pool and reallocated, turning the double-release into a use-after-free that can be leveraged for arbitrary read/write or code execution.

How to fix it

Apply the upstream kernel commit that sets all skip_release_bitmap bits in the common error path of mlx5e_xsk_alloc_rx_mpwqe; rebuild and boot the patched kernel on every affected system; until the update is installed, avoid enabling AF_XDP zero-copy on mlx5e interfaces.

How to confirm the fix worked

Confirm the patch is present by inspecting mlx5e_xsk_alloc_rx_mpwqe for the full bitmap set on error; reproduce the original scenario with fault injection forcing three consecutive allocation failures and verify each buffer is released only once; run a 20-second AF_XDP zero-copy pressure test and confirm absence of invalid descriptors or warnings.

Typical attack path

1. Open AF_XDP socket on mlx5e striding RQ
2. Apply memory pressure or fault injection to induce -ENOMEM during mlx5e_xsk_alloc_rx_mpwqe
3. Trigger NAPI poll that retries the same MPWQE
4. Cause mlx5e_free_rx_mpwqe to operate on stale pointers
5. Exploit resulting use-after-free for memory corruption or privilege escalation

How to detect it

Search kernel logs for repeated mlx5e allocation failures followed by WQE retry messages or use-after-free warnings; inspect AF_XDP socket activity and NAPI poll traces around the time of any mlx5e descriptor errors.

What your security team should do

• Immediately identify all hosts running mlx5e with AF_XDP and schedule emergency kernel updates
• Temporarily disable AF_XDP sockets on unpatched systems if the workload permits
• Add kernel oops and mlx5e XSK warning patterns to SIEM alerting
• Re-test AF_XDP functionality after patching with the supplied fault-injection scenario