Re: [PATCH net v2] net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete

[Simon Horman]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete

This commit fixes a use-after-free in the MACsec RX datapath by replacing
a synchronous metadata_dst_free() with dst_release() when an RX SC is
deleted. It also updates the datapath to use dst_hold_safe() to avoid
acquiring a reference to a dying destination entry.

> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c
> @@ -829,7 +829,7 @@ static void macsec_del_rxsc_ctx(struct mlx5e_macsec *macsec, struct mlx5e_macsec
>  	 */
>  	list_del_rcu(&rx_sc->rx_sc_list_element);
>  	xa_erase(&macsec->sc_xarray, rx_sc->sc_xarray_element->fs_id);
> -	metadata_dst_free(rx_sc->md_dst);
> +	dst_release(&rx_sc->md_dst->dst);
>  	kfree(rx_sc->sc_xarray_element);

[Severity: Critical]
This is a pre-existing issue, but is it safe to synchronously call kfree()
on rx_sc->sc_xarray_element here?

The RX datapath accesses the xarray under rcu_read_lock() in
mlx5e_macsec_offload_handle_rx_skb(). If sc_xarray_element is fetched via
xa_load() by a concurrent reader just before xa_erase() runs, won't this
kfree() free the element while the reader is still accessing it, leading to
a use-after-free?

>  	kfree_rcu_mightsleep(rx_sc);
>  }

[ ... ]

> @@ -1697,8 +1697,8 @@ void mlx5e_macsec_offload_handle_rx_skb(struct net_device *netdev,
>  	sc_xarray_element = xa_load(&macsec->sc_xarray, fs_id);
>  	rx_sc = sc_xarray_element->rx_sc;

[Severity: Critical]
This isn't a bug introduced by this patch, but does xa_load() return NULL
if the fs_id has already been erased by xa_erase() in the deletion path?

If packets matched by hardware before the rule was deleted are still
lingering in the software RX queues, xa_load() might return NULL.
Dereferencing sc_xarray_element->rx_sc immediately after could cause a
NULL pointer dereference. Could we add a NULL check here before accessing
sc_xarray_element?

[Severity: Critical]
This is also a pre-existing issue, but is rx_sc fully initialized when it
becomes visible to RCU readers?

In mlx5e_macsec_add_rxsc(), it appears sc_xarray_element is published to
the xarray via xa_alloc() before rx_sc->md_dst is allocated and
initialized:

mlx5e_macsec_add_rxsc() {
    ...
    err = xa_alloc(&macsec->sc_xarray, &sc_xarray_element->fs_id, ...);
    ...
    rx_sc->md_dst = metadata_dst_alloc(0, METADATA_MACSEC, GFP_KERNEL);
    ...
}

Since xa_alloc() assigns the lowest available index, the new fs_id could be
recycled from a recently deleted SC. If a lingering packet with the old
fs_id is processed by the datapath, it could find the newly published
element and attempt to call dst_hold_safe(&rx_sc->md_dst->dst).

Because rx_sc->md_dst is still NULL at that moment, could this cause a NULL
pointer dereference?

>  	if (rx_sc) {
> -		dst_hold(&rx_sc->md_dst->dst);
> -		skb_dst_set(skb, &rx_sc->md_dst->dst);
> +		if (dst_hold_safe(&rx_sc->md_dst->dst))
> +			skb_dst_set(skb, &rx_sc->md_dst->dst);
>  	}
>  
>  	rcu_read_unlock();