Each CEQ interrupt handler only schedules eqc->tasklet. The tasklet calls
erdma_ceq_completion_handler(), which reads the DMA-coherent EQ ring
through get_next_valid_eqe() and updates eq->dbrec through notify_eq().

erdma_ceqs_uninit() frees each CEQ IRQ and then destroys its EQ.
free_irq() prevents another hard IRQ and waits for an in-flight handler,
but it does not drain a tasklet that the handler already scheduled. The
tasklet can therefore access eq->qbuf or eq->dbrec after
erdma_eq_destroy() frees them.

Clearing ceq_cb->ready does not synchronize with a tasklet that already
passed the check at the start of erdma_ceq_completion_handler().

Kill the tasklet after free_irq(), when no handler can schedule it again,
and before erdma_ceq_uninit_one() releases the EQ buffers.

Fixes: f2a0a630b953 ("RDMA/erdma: Add event queue implementation")
Cc: stable@vger.kernel.org
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
---
Found by static analysis only; not tested on ERDMA hardware. Testing on
hardware, particularly device removal while CEQ interrupts are active,
would be appreciated.

 drivers/infiniband/hw/erdma/erdma_eq.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/hw/erdma/erdma_eq.c b/drivers/infiniband/hw/erdma/erdma_eq.c
index d5b9d19882b2..a8784e07acd6 100644
--- a/drivers/infiniband/hw/erdma/erdma_eq.c
+++ b/drivers/infiniband/hw/erdma/erdma_eq.c
@@ -220,6 +220,7 @@ static void erdma_free_ceq_irq(struct erdma_dev *dev, u16 ceqn)
 
 	irq_set_affinity_hint(eqc->irq.msix_vector, NULL);
 	free_irq(eqc->irq.msix_vector, eqc);
+	tasklet_kill(&eqc->tasklet);
 }
 
 static int create_eq_cmd(struct erdma_dev *dev, u32 eqn, struct erdma_eq *eq)
-- 
2.47.1

On Tue, 21 Jul 2026 17:25:45 +0900, Myeonghun Pak wrote:
> Each CEQ interrupt handler only schedules eqc->tasklet. The tasklet calls
> erdma_ceq_completion_handler(), which reads the DMA-coherent EQ ring
> through get_next_valid_eqe() and updates eq->dbrec through notify_eq().
> 
> erdma_ceqs_uninit() frees each CEQ IRQ and then destroys its EQ.
> free_irq() prevents another hard IRQ and waits for an in-flight handler,
> but it does not drain a tasklet that the handler already scheduled. The
> tasklet can therefore access eq->qbuf or eq->dbrec after
> erdma_eq_destroy() frees them.
> 
> [...]

Applied, thanks!

[1/1] RDMA/erdma: Fix CEQ tasklet use-after-free on removal
      https://git.kernel.org/rdma/rdma/c/0ca79979384f03

Best regards,
-- 
Leon Romanovsky <leon@kernel.org>

On 7/21/26 4:25 PM, Myeonghun Pak wrote:
> Each CEQ interrupt handler only schedules eqc->tasklet. The tasklet calls
> erdma_ceq_completion_handler(), which reads the DMA-coherent EQ ring
> through get_next_valid_eqe() and updates eq->dbrec through notify_eq().
> 
> erdma_ceqs_uninit() frees each CEQ IRQ and then destroys its EQ.
> free_irq() prevents another hard IRQ and waits for an in-flight handler,
> but it does not drain a tasklet that the handler already scheduled. The
> tasklet can therefore access eq->qbuf or eq->dbrec after
> erdma_eq_destroy() frees them.
> 
> Clearing ceq_cb->ready does not synchronize with a tasklet that already
> passed the check at the start of erdma_ceq_completion_handler().
> 
> Kill the tasklet after free_irq(), when no handler can schedule it again,
> and before erdma_ceq_uninit_one() releases the EQ buffers.
> 
> Fixes: f2a0a630b953 ("RDMA/erdma: Add event queue implementation")
> Cc: stable@vger.kernel.org
> Co-developed-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> ---
> Found by static analysis only; not tested on ERDMA hardware. Testing on
> hardware, particularly device removal while CEQ interrupts are active,
> would be appreciated.
> 
>  drivers/infiniband/hw/erdma/erdma_eq.c | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Cheng Xu <chengyou@linux.alibaba.com>

Thanks.

While this is unlikely to happen in practice, since the ibdev has already
been removed and no CQs should remain to generate CEQ events, this patch
makes the CEQ teardown ordering explicit and robust.

Cheng Xu


> diff --git a/drivers/infiniband/hw/erdma/erdma_eq.c b/drivers/infiniband/hw/erdma/erdma_eq.c
> index d5b9d19882b2..a8784e07acd6 100644
> --- a/drivers/infiniband/hw/erdma/erdma_eq.c
> +++ b/drivers/infiniband/hw/erdma/erdma_eq.c
> @@ -220,6 +220,7 @@ static void erdma_free_ceq_irq(struct erdma_dev *dev, u16 ceqn)
>  
>  	irq_set_affinity_hint(eqc->irq.msix_vector, NULL);
>  	free_irq(eqc->irq.msix_vector, eqc);
> +	tasklet_kill(&eqc->tasklet);
>  }
>  
>  static int create_eq_cmd(struct erdma_dev *dev, u32 eqn, struct erdma_eq *eq)

Hi,

I was looking at this driver and was curious if you also need
some type of synchronization after the xa_erase in erdma_destroy_cq.

Otherwise, it seems like the CEQ tasklet could do the xa_load right
before erdma_destroy_cq does the xa_erase, then destroy_cq proceeds
to return and kfree the CQ while the tasket is in the middle of comp_handler.

Most drivers either do a synchronize_irq (which I don't think would work for
this since it's a tasklet) or some form of locked refcounting when
accessing the xarray.

Thanks,
Jake

On 7/21/26 9:24 PM, Jacob Moroni wrote:
> Hi,
> 
> I was looking at this driver and was curious if you also need
> some type of synchronization after the xa_erase in erdma_destroy_cq.
> 
> Otherwise, it seems like the CEQ tasklet could do the xa_load right
> before erdma_destroy_cq does the xa_erase, then destroy_cq proceeds
> to return and kfree the CQ while the tasket is in the middle of comp_handler.
> 
> Most drivers either do a synchronize_irq (which I don't think would work for
> this since it's a tasklet) or some form of locked refcounting when
> accessing the xarray.
> 

Hi Jacob,

Thanks for pointing this out.

For kernel CQs this should be unlikely in practice, since the associated
QPs are destroyed first and the kernel QP destroy path drains the WQEs
before the CQ is destroyed.

However, the user CQ path does not have the same guarantee, so the race
you described still needs to be handled. We need to add synchronization
in the CQ destroy path, and I will take a closer look at this.

Thanks,
Cheng Xu

> Thanks,
> Jake