In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent stale XSK…

Why it is Amber

• CVSS 9.8 critical
• Remotely exploitable without logging in
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/32bbb870078d467479965c21bbc4960c57eea208
• https://git.kernel.org/stable/c/34d1db2b18e1c1d189e34dd51923e031815f88e3
• https://git.kernel.org/stable/c/639522e5056cade578a324acfa993ec6c9f7f5dc
• https://git.kernel.org/stable/c/655f47477054d19de3b138840be229a1a4490d0c
• https://git.kernel.org/stable/c/e01620844c5c88b6fcf819d171df8e3976a0e76f

Original description

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.