Re: [PATCH net-next v8 1/4] net: mana: prepare HWC ownership for safe reinitialization

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] net: mana: Use-after-free of CQ objects during teardown due to missing RCU sync
--

commit 2740a958c23f5ddb6759715d592fec4a687478f3
Author: Long Li <longli@microsoft.com>

net: mana: prepare HWC ownership for safe reinitialization

Dynamic HWC queue sizing tears down the bootstrap queues and establishes a
second channel before publishing it. Prepare the existing HWC ownership and
teardown paths so that sequence cannot free or reuse state still reachable
by either the PF or an EQ handler.

Link: https://lore.kernel.org/r/20260908035201.402424-2-longli@microsoft.com
Link: https://lore.kernel.org/r/20260908035201.402424-5-longli@microsoft.com
Link: https://lore.kernel.org/r/178910960115.219967.13830871915506436112@kernel.org
Link: https://lore.kernel.org/r/179196575238.434549.10775387794024020898@kernel.org
Link: https://lore.kernel.org/r/sashiko-outbox-170992@kernel.org

> diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
> +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c

[ ... ]

> @@ -765,11 +767,16 @@ static void mana_gd_process_eqe(struct gdma_queue *eq)
>  	switch (type) {
>  	case GDMA_EQE_COMPLETION:
>  		cq_id = eqe->details[0] & 0xFFFFFF;
> -		if (WARN_ON_ONCE(cq_id >= gc->max_num_cqs))
> +		/* The IRQ handler's RCU read-side section protects the table
> +		 * until HWC teardown has fenced its EQ and waited for readers.
> +		 */
> +		cq_table = smp_load_acquire(&gc->cq_table);
> +		if (!cq_table || cq_id >= READ_ONCE(gc->max_num_cqs))
>  			break;
>  
> -		cq = gc->cq_table[cq_id];
> -		if (WARN_ON_ONCE(!cq || cq->type != GDMA_CQ || cq->id != cq_id))
> +		cq = READ_ONCE(cq_table[cq_id]);
> +		if (!cq || WARN_ON_ONCE(cq->type != GDMA_CQ ||
> +					cq->id != cq_id))
>  			break;
>  
>  		if (cq->cq.callback)
>  			cq->cq.callback(cq->cq.context, cq);

[Severity: High]
Does this sequence still leave a use-after-free regression for Ethernet and
RDMA queues during teardown?

While this patch adds RCU documentation and memory barriers for the hardware
channel (HWC), it appears the teardown order issue remains for Ethernet
queues. During teardown, mana_detach() destroys CQs before EQs:

drivers/net/ethernet/microsoft/mana/mana_en.c:mana_detach() {
    ...
    mana_destroy_rxqs(apc);
    mana_destroy_txq(apc);
    mana_destroy_eq(apc);
}

When the CQ is destroyed, mana_gd_destroy_cq() unpublishes the CQ, and then
mana_gd_destroy_queue() immediately frees the queue memory via kfree()
without an RCU grace period:

drivers/net/ethernet/microsoft/mana/gdma_main.c:mana_gd_destroy_queue() {
    ...
    case GDMA_CQ:
        mana_gd_destroy_cq(gc, queue);
        break;
    ...
    mana_gd_destroy_dma_region(gc, gmi->dma_region_handle);
    mana_gd_free_memory(gmi);
    kfree(queue);
}

Because the EQ hasn't been fenced yet, an in-flight EQ interrupt could
execute mana_gd_process_eqe() concurrently. Since the RCU read-side
critical section here does not protect against kfree(), could it
dereference the freed memory when invoking cq->cq.callback() for these
queues?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1791998462.git.weh@linux.microsoft.com?part=1