2023-07-28 02:51:45

by Mark Zhang

[permalink] [raw]
Subject: Re: use-after-free in debug_spin_lock_before invoked the rdma driver

On 7/28/2023 8:45 AM, Zheng Zhang wrote:
> *External email: Use caution opening links or attachments*
>
>
> Jason, Leon, Mark Zhang, Mark Bloch and  to whom it may concern:
>
> Hello! We have found a bug in the Linux kernel version 6.2.0 by
> Syzkaller with our own templates. In the call trace it invoked the rdma
> driver, thus we think it may be different from the reported case invoked
> io_ring whose fix is also in the io_ring module.
> Unfortunately, it doesn't generate a reproducer.
>
> Attached is the report, log generated by syzkaller.
> Please let me know if there is any additional information that I can
> provide to help debug this issue.
> Thanks!
> Best
> zheng
>
Hi Zheng,

Thank you very much for reporting. Is it easy to reproduce? Can you
please help test with this patch, thanks:

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 1ee87c3aaeab..76810aac1809 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -3491,11 +3491,13 @@ static void addr_handler(int status, struct
sockaddr *src_addr,
event.event = RDMA_CM_EVENT_ADDR_RESOLVED;

if (cma_cm_event_handler(id_priv, &event)) {
+ cma_id_put(id_priv);
destroy_id_handler_unlock(id_priv);
return;
}
out:
mutex_unlock(&id_priv->handler_mutex);
+ cma_id_put(id_priv);
}

static int cma_resolve_loopback(struct rdma_id_private *id_priv)
@@ -4107,6 +4109,9 @@ int rdma_resolve_addr(struct rdma_cm_id *id,
struct sockaddr *src_addr,
rdma_addr_cancel(&id->route.addr.dev_addr);
else
id_priv->used_resolve_ip = 1;
+
+ /* Balances with cma_id_put() in addr_handler */
+ cma_id_get(id_priv);
ret = rdma_resolve_ip(cma_src_addr(id_priv), dst_addr,
&id->route.addr.dev_addr,
timeout_ms, addr_handler,