From: Bernard Metzler <bernard.metzler@linux.dev>
To: Shuangpeng Bai <shuangpeng.kernel@gmail.com>,
jgg@ziepe.ca, leon@kernel.org
Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] RDMA/siw: Fix use-after-free in siw_accept()
Date: Tue, 18 Aug 2026 18:33:16 +0200 [thread overview]
Message-ID: <51f3705f-6338-4892-86cb-d059e8101f8a@linux.dev> (raw)
In-Reply-To: <20260801213632.1086548-1-shuangpeng.kernel@gmail.com>
On 01.08.2026 23:36, Shuangpeng Bai wrote:
Sorry I was away for 3 weeks and can review only now.
> siw_accept() looks up the QP supplied by userspace. If that QP is
> already in RTS, the function jumps to error cleanup before associating
> the incoming CEP with it.
>
We test against any QP state other than expected
SIW_EPSTATE_RECVD_MPAREQ. The QP should never be in RTS here, since
it moves to RTS only after the user issued this accept we are in
and the RDMA CM core code makes sure a user does that only one time
per QP.
We typically end up in that error path, if the user spent to much time
in a new connection indication/accept path, while the peer already
closed that half open connection. So I don't follow that comment above.
Were you able to force such state mismatch?
> The cleanup tests whether qp->cep is non-NULL and assumes the current
> call installed the association. However, qp->cep can point to the CEP
> of an existing connection. The cleanup then drops a reference from the
Can that happen? QP numbers should be unique, maintained by
xa_alloc()/xa_erase(). A cep cannot be transferred among QP's.
> incoming cep, not qp->cep. Once the incoming endpoint loses its
> remaining references, this can free it before the subsequent cep->qp
> store, causing a use-after-free. It also clears the existing QP
> association.
>
> Only release the association reference when qp->cep is the incoming
> CEP. This preserves an existing association and avoids accessing the
> freed endpoint.
>
> Fixes: 6c52fdc244b5 ("rdma/siw: connection management")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
> ---
> drivers/infiniband/sw/siw/siw_cm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/sw/siw/siw_cm.c b/drivers/infiniband/sw/siw/siw_cm.c
> index 87c79527ac09..0245b25e7271 100644
> --- a/drivers/infiniband/sw/siw/siw_cm.c
> +++ b/drivers/infiniband/sw/siw/siw_cm.c
> @@ -1751,7 +1751,7 @@ int siw_accept(struct iw_cm_id *id, struct iw_cm_conn_param *params)
> cep->state = SIW_EPSTATE_CLOSED;
>
> siw_free_cm_id(cep);
> - if (qp->cep) {
> + if (qp->cep == cep) {
Is it really possible we have (qp->cep != cep)?
Were you able to create such situation?
Did you run into use_after_free?
Thanks very much!
Bernard.> siw_cep_put(cep);
> qp->cep = NULL;
> }
prev parent reply other threads:[~2026-08-18 16:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-01 21:36 [PATCH] RDMA/siw: Fix use-after-free in siw_accept() Shuangpeng Bai
2026-08-06 10:50 ` Leon Romanovsky
2026-08-18 16:33 ` Bernard Metzler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51f3705f-6338-4892-86cb-d059e8101f8a@linux.dev \
--to=bernard.metzler@linux.dev \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=shuangpeng.kernel@gmail.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.