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

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

[Doruk Tan Ozturk]

When an offloaded MACsec RX SC is deleted, macsec_del_rxsc_ctx() released
the per-SC metadata_dst with metadata_dst_free(), which calls kfree()
unconditionally and ignores the dst reference count. The RX datapath in
mlx5e_macsec_offload_handle_rx_skb() looks up the SC under rcu_read_lock()
via xa_load() and, while still holding only the RCU read lock, takes a
reference with dst_hold() and attaches the dst to the skb with
skb_dst_set().

A reader that has already obtained the rx_sc pointer can therefore race
with the delete path:

  CPU0 (del_rxsc)                 CPU1 (rx datapath)
  --------------                  ------------------
                                  rcu_read_lock();
                                  rx_sc = xa_load(...)->rx_sc;
  xa_erase(...);
  metadata_dst_free(rx_sc->md_dst); /* kfree(), ignores refcount */
                                  dst_hold(&rx_sc->md_dst->dst); /* UAF */
                                  skb_dst_set(skb, &rx_sc->md_dst->dst);

metadata_dst_free() frees the object even though the datapath still holds
(or is about to take) a reference, so the subsequent dst_hold() /
skb_dst_set() and the later skb free operate on freed memory.

Fix the owner side by dropping the reference with dst_release() instead of
freeing unconditionally. dst_release() only schedules the RCU-deferred
dst_destroy() once the reference count reaches zero, so a concurrent reader
that still holds a reference keeps the object alive.

Dropping the owner reference is not sufficient on its own: once the owner
reference is the last one, dst_release() drops the count to zero and the
destroy is merely RCU-deferred. A racing reader that runs plain dst_hold()
on that already-dead dst gets rcuref_get() == false but dst_hold() only
WARNs and attaches the dying dst to the skb anyway; the later skb free then
calls dst_release() on an object whose destroy is already
scheduled, again a use-after-free.

Convert the RX datapath to dst_hold_safe(), which returns false
(without warning) when the dst is already dead, and only attach it to
the skb when a reference was successfully taken. When the SC is being
deleted the in-flight packet simply proceeds without the offload
metadata_dst: skb_metadata_dst() returns NULL, the MACsec core sees
!is_macsec_md_dst and skips this secy (rx_uses_md_dst path), which is
the correct behaviour for a packet whose SC is going away.

Fixes: b7c9400cbc48 ("net/mlx5e: Implement MACsec Rx data path using MACsec skb_metadata_dst")
Cc: stable@vger.kernel.org
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
v2: also convert the RX datapath dst_hold() to dst_hold_safe() so a reader
    racing the SC delete cannot attach a dst whose last reference was just
    dropped (per the automated review forwarded by Simon Horman).

v1: https://lore.kernel.org/netdev/20260615140534.52691-1-doruk@0sec.ai/

 drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec.c
index 71b3a059c964..e5d9a14c92b8 100644
--- 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);
 	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;
 	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();
-- 
2.43.0

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();