Re: [PATCH net] net/mlx5: HWS, fix flow meter release on FTE update

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [High] net/mlx5: null pointer dereference in
  mlx5_fs_destroy_fs_action() [1]
--

commit a0812bfa068bccb4957fe6b500d9c96fead53b69
Author: Alexandre Cassen <acassen@corp.free.fr>

net/mlx5: HWS, fix flow meter release on FTE update

This commit stores the ASO meter base_id directly in struct
mlx5_fs_hws_rule_action instead of keeping a pointer to the FTE's exe_aso,
preventing FTE updates from releasing the new rule's meter action.

> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
> index 812b2f3cddcff..cbcbc2b62809d 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c
[ ... ]
> @@ -704,7 +704,7 @@ static void mlx5_fs_destroy_fs_action(struct mlx5_flow_root_namespace *ns,
>  		mlx5_fc_put_hws_action(fs_action->counter);
>  		break;
>  	case MLX5HWS_ACTION_TYP_ASO_METER:
> -		mlx5_fs_put_action_aso_meter(fs_ctx, fs_action->exe_aso);
> +		mlx5_fs_put_action_aso_meter(fs_ctx, fs_action->aso_base_id);
>  		break;
>  	case MLX5HWS_ACTION_TYP_SAMPLER:
>  		mlx5_fs_put_dest_action_sampler(fs_ctx, fs_action->sampler_id);
> @@ -937,7 +937,7 @@ static int mlx5_fs_fte_get_hws_actions(struct mlx5_flow_root_namespace *ns,
>  			fte_action->exe_aso.flow_meter.init_color;
>  		(*ractions)[num_actions++].action = tmp_action;
>  		fs_actions[num_fs_actions].action = tmp_action;
> -		fs_actions[num_fs_actions++].exe_aso = &fte_action->exe_aso;
> +		fs_actions[num_fs_actions++].aso_base_id = fte_action->exe_aso.base_id;
>  	}
>  
>  	if (fte_action->action & MLX5_FLOW_CONTEXT_ACTION_DROP) {

[Severity: High]
This problem wasn't introduced by this patch, but can
mlx5_fs_destroy_fs_action() dereference a NULL fs_action->action when
dest_action creation fails in mlx5_fs_fte_get_hws_actions() [1]?

Later in mlx5_fs_fte_get_hws_actions(), the MLX5_FLOW_DESTINATION_TYPE_RANGE
case (as well as MLX5_FLOW_DESTINATION_TYPE_FLOW_TABLE_NUM and
MLX5_FLOW_DESTINATION_TYPE_FLOW_SAMPLER) appends dest_action to fs_actions[]
and increments num_fs_actions before checking whether dest_action is NULL:

drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c:mlx5_fs_fte_get_hws_actions() {
	...
			case MLX5_FLOW_DESTINATION_TYPE_RANGE:
				dest_action = mlx5_fs_create_dest_action_range(ctx, dst);
				fs_actions[num_fs_actions++].action = dest_action;
				break;
			...
			}
			if (!dest_action) {
				err = -ENOMEM;
				goto free_actions;
			}
	...
free_actions:
	mlx5_fs_destroy_fs_actions(ns, fs_actions, num_fs_actions);
}

When mlx5_fs_create_dest_action_range() returns NULL, the free_actions
cleanup path passes that NULL entry to mlx5_fs_destroy_fs_action(), which
immediately dereferences fs_action->action in mlx5hws_action_get_type().

[1] https://sashiko.dev/#/bug/linux-13dff211-595e-45fa-ac59-340929fc7d57

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110173437.2471233-1-acassen@corp.free.fr?part=1