Re: [PATCH rdma-next v3 2/5] RDMA/mlx5: Fix UAF in DCT destroy due to race with create

[Jason Gunthorpe]

On Mon, Apr 27, 2026 at 02:02:33PM +0300, Edward Srouji wrote:
> A potential race condition exists between mlx5_core_destroy_dct() and
> mlx5_core_create_dct() that can lead to a use-after-free.
> 
> After _mlx5_core_destroy_dct() releases the DCT to firmware, the DCTN
> can be immediately reallocated for a new DCT being created concurrently.
> If the create path stores the new DCT in the xarray before the destroy path
> erases it, the destroy will incorrectly delete the new DCT's entry.
> Later accesses then hit freed memory.
> 
> Fix by replacing the unconditional xa_erase_irq() with xa_cmpxchg_irq()
> that only erases the entry if it hasn't already been replaced (still
> contains XA_ZERO_ENTRY), preserving any newly created DCT.
> 
> Fixes: afff24899846 ("RDMA/mlx5: Handle DCT QP logic separately from low level QP interface")
> Signed-off-by: Edward Srouji <edwards@xxxxxxxxxx>
> Reviewed-by: Michael Guralnik <michaelgur@xxxxxxxxxx>
> ---
>  drivers/infiniband/hw/mlx5/qpc.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/infiniband/hw/mlx5/qpc.c b/drivers/infiniband/hw/mlx5/qpc.c
> index 146d03ae40bd9fd9650530fba77eb7e942d5fe79..a7a4f9420271a228e161aaac1ffa432d304ce431 100644
> --- a/drivers/infiniband/hw/mlx5/qpc.c
> +++ b/drivers/infiniband/hw/mlx5/qpc.c
> @@ -314,7 +314,14 @@ int mlx5_core_destroy_dct(struct mlx5_ib_dev *dev,
>  		xa_cmpxchg_irq(&table->dct_xa, dct->mqp.qpn, XA_ZERO_ENTRY, dct, 0);
>  		return err;
>  	}
> -	xa_erase_irq(&table->dct_xa, dct->mqp.qpn);
> +
> +	/*
> +	 * A race can occur where a concurrent create gets the same dctn
> +	 * (after hardware released it) and overwrites XA_ZERO_ENTRY with
> +	 * its new DCT before we reach here. In that case, we must not erase
> +	 * the entry as it now belongs to the new DCT.
> +	 */
> +	xa_cmpxchg_irq(&table->dct_xa, dct->mqp.qpn, XA_ZERO_ENTRY, NULL, 0);
>  	return 0;

Sashiko is right about the 

xa_init_flags(&table->dct_xa, XA_FLAGS_LOCK_IRQ);

Please make another patch for that.

The think about the xa_cmpxchg_irq().. I think that is not sane.. If
the FW has returned the ID back to another thread then the FW is no
longer allowed to fail this destruction, it is already destroyed.

In this case the xa will go wonky, but we are already pretty lost at that
point.

The logic here is probably not great though, if the xa is mangled then
we should still try to do the firmware call

Jason