From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-11.mta0.migadu.com [91.218.175.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC747352029 for ; Fri, 21 Aug 2026 15:34:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787326451; cv=none; b=XoawEVC6wkAxvYJEe0imeUjeyjVV0632iLUdDqlvnV2uOV3ivU7PYze2ukJ0aYdhotRJXkPJKkO1ji/jeejXN+wY4cxfQawC1svOe2yyo6fduzy68gaxRxy0T4mdA9lc7goKeCWfeZWaMkR2bTuGB6B52ulOhaUK1bLsgQbZCZM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787326451; c=relaxed/simple; bh=GDeDMRIC3+kjhHvLLSuvAC6o4f9Zw7dcUeF95As8YS0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=On8Qsve8b3/FeRqFK/KghBo7pVgi6cNqA0nXQVWGo89WUrgocAhgZtjutQRyVk7Kt67VGouH8blNYmhFvO70odev6YbEm/frkvtBGWKvjHl23yPBsl3RyB0mxCoPC8sVRidDtdXyC4SDeBVr9U+OnJRL1LT9F8qJLiXC/pSTEgY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=FTB4hYH7; arc=none smtp.client-ip=91.218.175.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="FTB4hYH7" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=GDeDMRIC3+kjhHvLLSuvAC6o4f9Zw7dcUeF95As8YS0=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787326446; v=1; x=1787931246; b=FTB4hYH7agPgWOHEa8VTDxxYT//FMnqfdDdWTM/R4bnJnQKW4Gbf9WWryNSdl2mR8LXk/J3u KsBdGyriZVHyosBy7X3L0EDc025NI2fzCnuvpfF+iAtvfN8SuFGP9XEVCXzuyOe6KhVkX+6inx8 QTJtNHKml0RFaP+DyM6JVYZ0= X-Envelope-To: linux-kernel@vger.kernel.org Received: from [IPV6:2a04:ee41:4:15d4:8934:f21b:2683:d2a4] (2a04:ee41:4:15d4:8934:f21b:2683:d2a4) by smtp.migadu.com with ESMTPS id 401f72c286ba547a; Fri, 21 Aug 2026 15:34:06 +0000 X-Mizu-Trace-ID: 401f72c286ba547a X-Migadu-Flow: FLOW_OUT Message-ID: <51ecec6f-1a88-44a5-a089-951c757f95f3@linux.dev> Date: Fri, 21 Aug 2026 17:34:05 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] RDMA/siw: Fix CEP reference race in siw_accept() To: Shuangpeng Bai , jgg@ziepe.ca, leon@kernel.org Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20260816061353.4059242-1-shuangpeng.kernel@gmail.com> From: Bernard Metzler In-Reply-To: <20260816061353.4059242-1-shuangpeng.kernel@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 16.08.2026 08:13, Shuangpeng Bai wrote: > siw_accept() associates a CEP with the selected QP while holding > qp->state_lock. If the transition to RTS fails, the error path releases > the lock before detaching that association. > > The cleanup drops the QP association reference before clearing qp->cep. > A concurrent QP destroy can acquire qp->state_lock in between, observe > the stale pointer, and drop the same association reference again. This > can free the CEP before siw_accept() releases its remaining reference, > causing a use-after-free. Do we have a stack trace for that use-after-free?> > Serialize the error-side detachment with qp->state_lock and clear qp->cep > before dropping the association reference. This ensures that either the > accept cleanup or QP teardown removes the association, but not both. > > This is a follow-up to commit a93949718259 ("RDMA/siw: Fix > use-after-free in siw_accept()") and addresses a separate race in the > same error path. > > Fixes: 6c52fdc244b5 ("rdma/siw: connection management") > Link: https://patch.msgid.link/20260801213632.1086548-1-shuangpeng.kernel@gmail.com > Cc: stable@vger.kernel.org > Signed-off-by: Shuangpeng Bai > --- > drivers/infiniband/sw/siw/siw_cm.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/infiniband/sw/siw/siw_cm.c b/drivers/infiniband/sw/siw/siw_cm.c > index 0245b25e7271..da1b953f3fa3 100644 > --- a/drivers/infiniband/sw/siw/siw_cm.c > +++ b/drivers/infiniband/sw/siw/siw_cm.c > @@ -1751,11 +1751,13 @@ int siw_accept(struct iw_cm_id *id, struct iw_cm_conn_param *params) > cep->state = SIW_EPSTATE_CLOSED; > > siw_free_cm_id(cep); What can destroy the QP at this point? An appication QP destroy shall be serialized with this accept call by the RDMA core. A concurrent connection drop by peer side would affect QP state, but is serialized at the cep using siw_cep_set_inuse()/_free() I don't see other cases which are not serialized...? > + down_write(&qp->state_lock); > if (qp->cep == cep) { > - siw_cep_put(cep); > qp->cep = NULL; > + siw_cep_put(cep); > } > cep->qp = NULL; > + up_write(&qp->state_lock); > siw_qp_put(qp); > free_cep: > siw_cep_set_free_and_put(cep); > > base-commit: a9394971825933074032794a5feee5211509c774