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=1794585968; b=h88UBlyUvpazot1yYYK0nCvQgwURHY32yG1sEWZ5gwtYHAtICqcEoWs+MGNGOiMOwKcZ 6oQS8QJdRa5j08NfKuNYChZThZboUkZz4OtAZNBWAufNfvLonIkDcs+W0Tj9Wcz6UKIna 947ejKl9eTiGItewCHxrsWKeppWDIi74z+MihD/8DElO//rkwn1YzSEe/W5BDV48DoxQC qza0LuZJeiOCyltVzVfXVOzHUQ6Ww+LSuWIla1vlq32k9NsJphME2AnIIxGNscaf4WQim 5h60VwADo0QzV4f+5mKBdqEEJX9HvUGy0Gl4Cmm0pvW7kq/qGTLnucSKobR++ltLV2w== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794585968; 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=NFzERumTAYVqH7D8hNLGydIx2nFAPz1wzmW+Ve66RPo=; b=azXG2+G02Qsj6bj+M0VDL+ObmgU3io0UkKWjVsmDX0sGw9h4fhoF77SAhNFcgHls3wGO h0dgduMHrhNRLQlqCdX2qX+XjviBNolezLJjP0TAU7kNkf+9WmbzfBVMHve1xu5LJ6x5W HMQVfyaa8x/4l6du2BIh3XQ2F2I7iOrZZNqQPaA+GD9P0nGz7OJq9eVel5N0Z4n99fFBC hwUMnALogxtv4Cw5ikJ3gOuRGAnkOcm56SiKlUfhBLW1gpGjI7QqM7UKk8NEwLDR4zXKq RUYBqX1Y1kdo4AtpqedY6RVzfNgdmA+3PaxS9JcNMt8CCdiLRvz7sXsZ8B3p9jUmY2g== 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="QbZiO/OC"; 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 558E46072300; Fri, 13 Nov 2026 16:06:08 +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=QbZiO/OC Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00CAC1F000C4; Fri, 13 Nov 2026 16:06:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794585968; bh=NFzERumTAYVqH7D8hNLGydIx2nFAPz1wzmW+Ve66RPo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=QbZiO/OCQVnVwTLKwnrhkW55fDkIoEUw9yBrLvr2kzsBuphIKyaEOkHDj0zkEvX3I SSYB80IyqIQxMQYa/f/gAYEXxfeFVnpIOcUhuriGN0F0K3ch6rkxYUyBTBpcSvO+Rw Bjv5xBaZyL/7KW56UioEA5s+Pki9PM7Y5HIgwBEs= 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.18 009/686] Bluetooth: L2CAP: Only accept connection responses to outstanding requests Date: Fri, 13 Nov 2026 10:42:22 -0500 Message-ID: <20261113153821.243438469@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261113153820.902362109@linuxfoundation.org> References: <20261113153820.902362109@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.18-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 52ff1b8785d77..22bac1222fab7 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) { @@ -4297,7 +4319,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; } @@ -4310,8 +4332,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