Re: [PATCH net-next 4/6] net/mlx5: HWS, Add timeout mechanism to draining send queues

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] mlx5: HW UAF when queue drain timeout leaves pending WQEs
- [Medium] mlx5: false timeout error when send queue drains exactly at timeout boundary
--

commit 61f83bb352e1062985b4a65a41c453e002f769ea
Author: Yevgeny Kliteynik <kliteyn@nvidia.com>

net/mlx5: HWS, Add timeout mechanism to draining send queues

This commit introduces a timeout mechanism for draining send queues in the
hardware steering (HWS) layer, returning an error if polling exceeds the
timeout limit.

[ ... ]
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/send.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/send.c
> index 49dee44d0bef5..9ff109fc8230a 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/send.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/send.c
[ ... ]
> @@ -1213,9 +1215,18 @@ int mlx5hws_send_queue_action(struct mlx5hws_context *ctx,
>  			mlx5hws_send_engine_flush_queue(queue);
>  
>  		/* Poll queue until empty */
> -		while (wait_comp && !mlx5hws_send_engine_empty(queue))
> +		while (wait_comp && !mlx5hws_send_engine_empty(queue)) {
>  			hws_send_engine_poll_cq(queue, NULL, &polled, 0);
>  
> +			if (unlikely(time_after(jiffies, timeout))) {

[Severity: Medium]
If the queue successfully drains on this exact iteration, or if the thread
is preempted after polling and before the timeout check, does this
unconditionally return -ETIMEDOUT?

Since hws_send_engine_poll_cq() processes the completions, checking the
timeout immediately without verifying if the queue is now empty might
cause callers to improperly abort and roll back fully successful operations.

> +				mlx5hws_err(ctx,
> +					    "Error draining send queue %d - TIMEOUT (%d sec)\n",
> +					    queue_id,
> +					    MLX5HWS_BWC_POLLING_TIMEOUT);
> +				return -ETIMEDOUT;

[Severity: High]
When returning -ETIMEDOUT here, the send queue still contains pending
hardware WQEs that are not cleared or aborted. Can this lead to a
hardware use-after-free?

Callers react to this error by destroying the allocated hardware resources.
For example, if mlx5hws_arg_create() receives the timeout error:

mlx5hws_arg_create()
    mlx5hws_arg_write_inline_arg_data()
        mlx5hws_send_queue_action()  <-- times out
    if (err)
        mlx5hws_cmd_arg_destroy(ctx->mdev, id); // id is freed

Because the hardware queue is not stopped and the pending WQEs are not
aborted, couldn't the firmware later process the stuck WQE and write to
the freed resource ID, potentially corrupting firmware state or crashing?

> +			}
> +		}
> +
>  		break;
>  	default:
>  		return -EINVAL;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915111912.3926585-1-tariqt@nvidia.com?part=4