Tariq Toukan

The issue arises in the net/mlx5e component of the Linux kernel, specifically with the SHAMPO feature. When all strides in a Work Queue Element (WQE) are consumed, the WQE is unlinked from the Work Queue (WQ) linked list using the `mlx5 wq ll pop()` function. However, for SHAMPO, it's possible to receive Completion Queue Entries (CQEs) with 0 consumed strides for the same WQE even after it's fully consumed and unlinked. This triggers an additional unlink for the same WQE, corrupting the linked list. The fix involves accepting 0-sized consumed strides without unlinking the WQE again.

The issue arises in the Linux kernel's net/mlx5e module, specifically with the SHAMPO (Shared Header And Memory Pool Optimization) feature. Under certain conditions, a new skb (socket buffer) is formed with a regular data page instead of a SHAMPO header page. Later, in the `mlx5e handle rx cqe mpwrq shampo()` function, a SHAMPO header page is released from the `header index`. This leads to SHAMPO header pages being released more than once, which is incorrect. The conditions for this to occur are: 1) no skb has been created yet, 2) `header size` equals 0 (indicating no SHAMPO header), and 3) `header index + 1 % MLX5E SHAMPO WQ HEADER PER PAGE` equals 0, marking the last page fragment of a SHAMPO header page.

The issue allows local users to gain privileges or cause a denial of service (use-after-free) by leveraging improper access to a certain error field in the ext4 journal stop function.