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=1794590821; b=G/r3m/7mKyVpoDgq9Fcp3VHTKZ34Ks/TssIJQJ+QC6aqCZOls1XFlFf+hhxdM0P9c74V 5UkOLxQQUYfV5TLelLngA+pNdPQN6sKqdkUId8i/CdvnzxsKGLH+ELs59wDart0s+PY7R Wrplesqml+WIFsM8tk/5NfpZIhJix5xwlfHbvMY+1s3knE4JHN7F40AHoawEIclkqo0Dn TaoHfdDwCw+oIWgEMJByggZ/kIsMPtcmWmaQkPbzhDLzp+L+WCpXK1GtB+exFvSc6rsTs EXPfEilhnaXvzzHOwBlRQj6byVWjXF/ZReWorQh9C2yt29B2s1qBx+nJdrsZ6P+pgOw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794590821; 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=TPSDd9Qgx3gt2VHZatBH41d0kkqSQF8TYZpmZX44iV0=; b=zSt2zXIDo+MKQsfmsa8+eNnx2FC2ti4UgunbkROFJ9/4Jae2s7QE3HEVtBxTUUtYJOBT 8icLmXtDnXRh49W0YObPIXKc2FayHGQ3EdCOExG9PSFIkTrl7GSXlbkzQ/jNdEB5V0Qq3 X5VSvHD+PpEV953v9C/EMrENvpCDl2ZoVdJoweyRlnOQYva5qELsItOsV3uRKqSUbYBbs U9uNfg+Kr3dpAFzyuaW8y8gqyBeW2/YQueNMnQoM6ukl1OXJm4J5YUW5IXzMhXX/BrWts k0Ft4V9FBcloJnJwpB8RVi7g8hN0W+kQV4BFuWGa9c1nbVnoVo5s1YZyRjo08oUxzLg== 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=R7gtN+Bn; 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 0C327607E053; Fri, 13 Nov 2026 17:27:01 +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=R7gtN+Bn Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD86E1F000C4; Fri, 13 Nov 2026 17:27:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794590820; bh=TPSDd9Qgx3gt2VHZatBH41d0kkqSQF8TYZpmZX44iV0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=R7gtN+BnzDo8qp2meLjov0KqAzUgWil92stWUdneMx/yFg2VGvRucYCTURKePXuIX 5MifX9cJsG0na7IIxAmSyBk/kFAHKJNCJtes6kJrP2LhQgwJAMsIPrdDljD8VVQhms R5puUwGO9oLy1dwazBcBh3dqv08d5j/qJhg0i71I= 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 6.12 010/670] Bluetooth: L2CAP: Only accept connection responses to outstanding requests Date: Fri, 13 Nov 2026 10:42:54 -0500 Message-ID: <20261113153811.532127311@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261113153811.177190860@linuxfoundation.org> References: <20261113153811.177190860@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 6.12-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 fa7124c32d91a..2f107c036dd4d 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -161,6 +161,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) { @@ -4265,7 +4287,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; } @@ -4278,8 +4300,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