From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794585231; b=1KTTlatQBnAlk/xL9BF32GmnuJFgZ0KukYq8Pci/tT3EmmGT7mgLBl4uxu4hU8/IOmo4 J7hjzY4GvDv7IyuyIaB4+7NC5yEgbhMIiEubz5U4Q1v9/PfhXPP+MkUHJFhxGIKQL2Gm6 ctYhwmgjO+0ZcIZfnp56la1IaqfopiLOG67M6w4QvajgdKLr80uZEYp6y99fBsRIwUo3/ QkoSAWJay5V2QXVCPsb6PGtZNb9TWs5DuaEgnG4mMhbdfj+UWPoQ1lxNRVZIpPG1DqNZA Xb9hC40QaEsS1IpPc26aiztpHuhxe7YLzECWQbrQwI804NLW8fo7p6lKDLzkijLcSWw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794585231; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=jWblw/WnCTbtslz4DkRvE9/RJe4PiruCdXlavHJ7tgs=; b=ZEGppkZDX7NWPP2BUIjVPwEEK85g0aHgQfTHVE/bwWURuUufSU2AFYeY/SWsd4uZkG4F zjFGg8sTzIYKl/jwcsJSI9udQiiu4+K8Eciemb6FdNzJAyM4UGap+PEouxq+TlXFG/HFt uJPehVZUVF7ebuByImU8f2kb/mj0p4T+a/6Ciw+i0n8e1OfLVA4sGXkMKqB07dYLx6tkT OCeyrSz5I7Ul+uCFWRfd4kZC1wNrFvGqDchs6zZ32MIwYOVbGGCLZ/MU82Ew/d2FWaClb ykxo2gXNG9qaHqKKJpSzdyaQb4c6l4toiW0oA7oKnbzhKSbxvN85gX1bG2sOZ7HpveQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=bHlUxHP4; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6DF43606A32E; Fri, 13 Nov 2026 15:53:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=bHlUxHP4 Received: by smtp.kernel.org (Postfix) with ESMTPSA id F38BD1F000C4; Fri, 13 Nov 2026 15:53:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794585231; bh=jWblw/WnCTbtslz4DkRvE9/RJe4PiruCdXlavHJ7tgs=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=bHlUxHP4+k6BZ8JuJZJF/EN57jREp89D/GkR7IwyRV7EvRkhhBKSfA7eWcCFA6AOU TSRIOcLkOWP/970WY59nkf8eZH7trr4wDu9dDLLpwO8K3BzDrMeGnA4dbLGm8SWnMC qKoD+Is5Qs9zURceHfSz7YqzXetauGZnb7eDaPkU= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Siwei Zhang , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 7.3 003/507] Bluetooth: L2CAP: Only accept connection responses to outstanding requests Date: Fri, 13 Nov 2026 10:45:07 -0500 Message-ID: <20261113153753.493475885@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261113153753.358973689@linuxfoundation.org> References: <20261113153753.358973689@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.3-stable review patch. If anyone has any objections, please let me know. ------------------ From: Siwei Zhang commit a518b9a9ef6ee3b18ecdf6ba5360c608aaf969e9 upstream. Adjusted context as stable does not have the lockdep_assert_held() call and the __must_hold() context analysis annotations. An outgoing channel waits in BT_CONNECT until security and the feature mask exchange complete, and only then sends its connection request. A peer can answer it before that with a connection response matching our source CID. The channel then moves to BT_CONFIG, completes configuration and becomes connected before security has completed. If security then fails, l2cap_security_cfm() leaves the connected channel alone, so it stays up on a link that did not reach the required security level. A connection response with a zero source CID is matched by identifier. Another channel can hold the same identifier for a response it still has to send, so the lookup can pick the wrong channel. Only accept a connection response while our request is outstanding, and only look at such channels when matching by identifier. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin --- net/bluetooth/l2cap_core.c | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index 3e57c605cf8be..01945c55e1b87 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -158,6 +158,28 @@ static struct l2cap_chan *__l2cap_get_chan_by_ident(struct l2cap_conn *conn, return NULL; } +/* Our connection request has been sent and is still outstanding */ +static bool l2cap_chan_connect_pending(struct l2cap_chan *chan) +{ + return chan->state == BT_CONNECT && + test_bit(CONF_CONNECT_PEND, &chan->conf_state); +} + +/* Other channels may hold the same ident for a response they still have + * to send, so only look at channels waiting for a connection response. + */ +static struct l2cap_chan *__l2cap_get_connect_chan_by_ident(struct l2cap_conn *conn, + u8 ident) +{ + struct l2cap_chan *c; + + list_for_each_entry(c, &conn->chan_l, list) { + if (c->ident == ident && l2cap_chan_connect_pending(c)) + return c; + } + return NULL; +} + static struct l2cap_chan *__l2cap_global_chan_by_addr(__le16 psm, bdaddr_t *src, u8 src_type) { @@ -4298,7 +4320,7 @@ static int l2cap_connect_create_rsp(struct l2cap_conn *conn, if (!chan) return -EBADSLT; } else { - chan = __l2cap_get_chan_by_ident(conn, cmd->ident); + chan = __l2cap_get_connect_chan_by_ident(conn, cmd->ident); if (!chan) return -EBADSLT; } @@ -4311,8 +4333,11 @@ static int l2cap_connect_create_rsp(struct l2cap_conn *conn, l2cap_chan_lock(chan); - /* Ignore a late response after the channel has left BT_CONNECT. */ - if (chan->state != BT_CONNECT) + /* Only accept a response to a connection request we sent and that + * is still outstanding. A channel waiting in BT_CONNECT for security + * or the feature mask has not sent one yet. + */ + if (!l2cap_chan_connect_pending(chan)) goto done; switch (result) { -- 2.53.0