CVE-2026-98367: RDMA/siw: Clear association under lock if siw_qp_modify fails in siw_accept
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Clear association under lock if siwqpmodify fails in siwaccept
We need to clear cep before release statelock as siwqpllpclose and siwqpmodify->siwqpllpclose did.
Otherwise if siwqpmodify() fails in siwaccept(), the QP's statelock is released before the error path cleanup. A concurrent ibvmodifyqp() transitioning the QP to ERROR can race in this window:
siwaccept() ibvmodifyqp(ERROR) ---------------------- ---------------------- siwqpmodify() fails upwrite(&qp->statelock) downwrite(&qp->statelock) nextstatefromidle(): if (qp->cep) siwcepput(qp->cep) <- frees cep qp->cep = NULL goto error cep->qp = NULL <- UAF
Clear qp->cep and drop the association reference taken by siwcepget(), all under the write lock held from the initial downwrite(&qp->statelock). Thread B therefore sees qp->cep == NULL, skips its own put, and cannot free the cep before siwaccept() is done with it.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this race?
Linux kernel deployments using the RDMA Software iWARP (siw) path are implicated. The race requires a queue pair accept operation to encounter a siw_qp_modify() failure while another thread concurrently modifies that queue pair to the ERROR state.
What is the impact if the race occurs?
The concurrent ERROR transition can release and free the connection endpoint (cep) while siw_accept() still accesses it during error cleanup. This results in a use-after-free condition.
What change addresses the issue?
The association is cleared and its reference dropped while the queue pair state_lock is still held. A concurrent modifier then observes a NULL qp->cep and does not free the endpoint before siw_accept() has finished using it.