In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent stale XSK buffer release on MPWQE refill retry
With AF_XDP on a striding RQ, mlx5e defers releasing XSK buffers until
an MPWQE is refilled. If XSK allocation then returns -ENOMEM,
actual_wq_head is not advanced and a later NAPI poll retries the same
WQE.
mlx5e_free_rx_mpwqe() leaves each released slot marked as releasable. On
retry it can therefore call xsk_buff_free() again through stale pointers
after the frames have returned to the XSK pool and been reallocated.
Set all skip_release_bitmap bits in the common error path of
mlx5e_xsk_alloc_rx_mpwqe(). This matches mlx5e_alloc_rx_mpwqe(). A
successful allocation already clears the bitmap after replacing every
buffer, so retries become idempotent without changing the success path.
Fault injection forced three consecutive failures for one selected MPWQE.
Both an early allocation failure and a partial 8-of-16-buffer unwind
released the original 16 XSK buffers only once. Each error left a full
bitmap, the following NAPI retry skipped the release, and a later
successful allocation cleared it. A 20-second AF_XDP zero-copy pressure
run exercised 1,575,262 buffer allocation failures without invalid
descriptors, WQE errors, or kernel warnings.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - Routable IP packets received by mlx5 consume the AF_XDP striding RQ through mlx5e_completion_event() -> mlx5e_napi_poll() -> mlx5e_poll_rx_cq(), after which mlx5e_napi_xsk_post() -> mlx5e_post_rx_mpwqes() reaches patched mlx5e_xsk_alloc_rx_mpwqe(); packet pressure exhausts the RX/Fill rings and triggers the stale-buffer retry.
AC:L - A sender can flood the XSK-bound RSS queue until XDP redirect and refill allocation fail, then continue traffic so NAPI retries the unchanged actual_wq_head; no uncontrolled race is needed for mlx5e_free_rx_mpwqe() to release the stale pointer.
PR:N - The receive path beginning at mlx5e_completion_event() performs no authentication or capability check; xsk_create()'s CAP_NET_RAW requirement applies to victim-side AF_XDP provisioning, while the remote IP sender needs no privileges.
UI:N - Once an mlx5 AF_XDP zero-copy pool and XDP program are running, packet receipt, mlx5e_napi_xsk_post(), and the refill retries occur automatically without further victim action.
S:U - The corrupted xsk_buff_pool metadata and mlx5 receive state belong to the host kernel; the bug crosses no VM, IOMMU, or other security-authority boundary.
C:H - In unaligned-UMEM mode, duplicate live xdp_buff_xsk ownership lets repeated successful __xsk_rcv_zc() calls make xp_release() write kernel pointers past the pool's flexible free_heads[] array; this heap corruption can be leveraged to disclose arbitrary kernel memory.
I:H - The same xp_release() overflow is an out-of-bounds kernel heap write; subsequent xp_get_xskb() trusts pointers popped from corrupted free_heads[] and initializes through them, supporting arbitrary writes or control-flow corruption.
A:H - Overflowing free_heads[] or later dereferencing a bogus xskb in xp_get_xskb() can oops or panic; even without a crash, duplicate UMEM ownership can prevent mlx5e_xsk_alloc_rx_mpwqe() from restoring WQEs and stop the bound receive queue.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - Routable IP packets received by mlx5 consume the AF_XDP striding RQ through mlx5e_completion_event() -> mlx5e_napi_poll() -> mlx5e_poll_rx_cq(), after which mlx5e_napi_xsk_post() -> mlx5e_post_rx_mpwqes() reaches patched mlx5e_xsk_alloc_rx_mpwqe(); packet pressure exhausts the RX/Fill rings and triggers the stale-buffer retry.
AC:L - A sender can flood the XSK-bound RSS queue until XDP redirect and refill allocation fail, then continue traffic so NAPI retries the unchanged actual_wq_head; no uncontrolled race is needed for mlx5e_free_rx_mpwqe() to release the stale pointer.
PR:N - The receive path beginning at mlx5e_completion_event() performs no authentication or capability check; xsk_create()'s CAP_NET_RAW requirement applies to victim-side AF_XDP provisioning, while the remote IP sender needs no privileges.
UI:N - Once an mlx5 AF_XDP zero-copy pool and XDP program are running, packet receipt, mlx5e_napi_xsk_post(), and the refill retries occur automatically without further victim action.
S:U - The corrupted xsk_buff_pool metadata and mlx5 receive state belong to the host kernel; the bug crosses no VM, IOMMU, or other security-authority boundary.
C:H - In unaligned-UMEM mode, duplicate live xdp_buff_xsk ownership lets repeated successful __xsk_rcv_zc() calls make xp_release() write kernel pointers past the pool's flexible free_heads[] array; this heap corruption can be leveraged to disclose arbitrary kernel memory.
I:H - The same xp_release() overflow is an out-of-bounds kernel heap write; subsequent xp_get_xskb() trusts pointers popped from corrupted free_heads[] and initializes through them, supporting arbitrary writes or control-flow corruption.
A:H - Overflowing free_heads[] or later dereferencing a bogus xskb in xp_get_xskb() can oops or panic; even without a crash, duplicate UMEM ownership can prevent mlx5e_xsk_alloc_rx_mpwqe() from restoring WQEs and stop the bound receive queue.
CVSS 3.1