Linux kernel (drivers/net/ethernet/mellanox/mlx5/core): When an XDP program shrinks a multi-fragment receive buffer

Impact

When an XDP program shrinks a multi-fragment receive buffer, the driver loses track of the fragments the XDP core already released, so the page-pool reference count on those pages goes negative. A negative refcount means pages are handed back to the allocator while the receive ring still owns them - page-pool accounting corruption on the RX path that ends in reuse of live DMA pages and node instability.

Who can reach it

Driven from the wire: a fabric peer sends frames large enough to span multiple receive fragments (jumbo / scattered payloads), and any XDP program on the interface that calls bpf_xdp_pull_data() or bpf_xdp_adjust_tail() triggers the miscount. Conditional on legacy (non-striding) RQ plus an attached XDP multi-buffer program - common on nodes running an XDP-based dataplane or eBPF firewall in front of tenants.

What to do

Update to 6.7.x / 6.13.x / 6.18 or later per your stream. Interim: detach XDP multi-buffer programs from mlx5 interfaces, or switch the interfaces to striding RQ so the legacy-RQ fragment path is not used.

References