RDMA/rxe: fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp
Subsystems (3)
PATCH v3 1/1 RDMA/rxe: fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp
rxe_qp_from_attr() handles IB_QP_MAX_DEST_RD_ATOMIC outside the IB_QP_STATE path, so it holds no state_lock and runs while the responder task rxe_receiver() (recv_task on rxe_wq) is live. A modify_qp() setting only that attribute calls free_rd_atomic_resources() then alloc_rd_atomic_resources(), swapping qp->resp.resources[] while rxe_prepare_res()/find_resource() walk it; free_rd_atomic_resources() also leaves the cached pointer qp->resp.res dangling. A local unprivileged user can race the free/realloc into a use-after-free in rxe_receiver() (local DoS).
Drain recv_task around the swap with rxe_disable_task()/rxe_enable_task(), as rxe_qp_reset() already does when tearing this array down, re-enabling only after alloc_rd_atomic_resources() succeeds so the responder never resumes against a NULL qp->resp.resources on the ENOMEM path. Also clear qp->resp.res in free_rd_atomic_resources(), like the rxe_resp.c completion paths.
Reproduced under KASAN; the slab-use-after-free in rxe_receiver() is gone.
---
v3: rewrite the commit message to describe the rxe_qp_from_attr() -> free/alloc_rd_atomic_resources() vs rxe_receiver() call flow directly and terse per Leon's review; resend as a standalone patch (not in-reply-to the previous series). No code change from v2; carries Zhu Yanjun's Reviewed-by.
drivers/infiniband/sw/rxe/rxe_qp.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)
drivers/infiniband/sw/rxe/rxe_qp.c +14 -1
@@ -172,6 +172,7 @@ static void free_rd_atomic_resources(struct rxe_qp *qp) }kfree (qp->resp.resources); qp->resp.resources =NULL ; + qp->resp.res =NULL ; } }
@@ -709,11 +710,23 @@ int rxe_qp_from_attr(struct rxe_qp *qp, struct ib_qp_attr *attr, int mask, qp->attr.max_dest_rd_atomic = max_dest_rd_atomic; +/* +* Not gated by IB_QP_STATE, so the responder task is live. +* Quiesce recv_task like rxe_qp_reset() before swapping the +* rd_atomic array, so rxe_receiver() cannot race the free/ +* realloc. +*/ +rxe_disable_task (&qp->recv_task);free_rd_atomic_resources (qp); - err =alloc_rd_atomic_resources (qp, max_dest_rd_atomic); +/* +* On ENOMEM leave recv_task quiesced: qp->resp.resources is +* NULL and rxe_prepare_res()/find_resource() would deref it. +* Re-enable only after a fresh array is installed. +*/ if (err)return err; +rxe_enable_task (&qp->recv_task); }if (mask &IB_QP_EN_SQD_ASYNC_NOTIFY )
Signature · 1 line
2.50.1 (Apple Git-155)
Leon Romanovsky
AppliedQuoted 11 lines · Ibrahim Hashimov
rxe_qp_from_attr()handlesIB_QP_MAX_DEST_RD_ATOMICoutside theIB_QP_STATEpath, so it holds nostate_lockand runs while the responder taskrxe_receiver()(recv_taskonrxe_wq) is live. Amodify_qp()setting only that attribute callsfree_rd_atomic_resources()thenalloc_rd_atomic_resources(), swapping qp->resp.resources[] while rxe_prepare_res()/find_resource() walk it;free_rd_atomic_resources()also leaves the cached pointerqp->resp.resdangling. A local unprivileged user can race the free/realloc into a use-after-free inrxe_receiver()(local DoS).[...]
Applied, thanks!
[1/1] RDMA/rxe: fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp
https://git.kernel.org/rdma/rdma/c/a37da605b395b9
Best regards,
Signature · 1 line
Leon Romanovsky <[email protected]>