From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B4AAD3DD851; Tue, 16 Jun 2026 19:07:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781636857; cv=none; b=FmCWSDsH4uKiw4PTo51TyyOrmfRCqNfPsB6IT6s3LhCKRiXuc6KNie+19wAY7g7YMrv8sJx/urQj3cMnAr/c1Nqc4LwtR8HmP87oqrwPHN4wd5BihwHWxnmda+JUxnE76lnQDALpSdCU+tUSRksuHJ3s6P8wBrh4uis4yy2Y8wY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781636857; c=relaxed/simple; bh=Zk/5KJJUKv2dU3PIebFYs8MeDwuKQucd8kuQ30+j79w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TO3zqPf+LmvmwFemhYKWLrc5ZiJLJ5Q+c3P2heFHUsK2XIycqIiF8rsn4EevRek7R3EGyWc9DMJDzf61nigSZQmbXS6o0fZIZLs4IkKwLE75BeXT8KIvkE76oelm4l6BLAGYK6SryUr2QWJGac802AKg5JTCT4mQH9uAgnhUCys= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=GS8eOTD3; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="GS8eOTD3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B43881F000E9; Tue, 16 Jun 2026 19:07:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1781636856; bh=NCdSs3CBZfXi6w0fO2BNzsc4ixtBAdZBegUFXWkEnNU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=GS8eOTD3m3PeakRl6RNZrud8IGkaeVqRzqmVLtH02BZKRTLDx8N3B1C04v9AJPDWl LYKFXG4KrsEEwG1pUR+T2SbfO0YiUpJct+u2FVD/ixGz55bIjIitE90eXGXJZeR7x9 n6uA3ECfXNf5b0+7cSLcO+vG0FLF2RTsYbcAFPqY= 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 5.10 317/342] Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen() Date: Tue, 16 Jun 2026 20:30:13 +0530 Message-ID: <20260616145103.298531085@linuxfoundation.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260616145048.348037099@linuxfoundation.org> References: <20260616145048.348037099@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 5.10-stable review patch. If anyone has any objections, please let me know. ------------------ From: Siwei Zhang [ Upstream commit 8c8e620467a7b51562dbcefbd1f09f288d7d710d ] l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared. Fixes: 3df91ea20e74 ("Bluetooth: Revert to mutexes from RCU list") Cc: # 0b58004: Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del() Signed-off-by: Siwei Zhang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- net/bluetooth/l2cap_sock.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) --- a/net/bluetooth/l2cap_sock.c +++ b/net/bluetooth/l2cap_sock.c @@ -1437,6 +1437,10 @@ static void l2cap_sock_cleanup_listen(st * pin it (hold_unless_zero() additionally skips a chan already past * its last reference). We then drop the sk lock before taking * chan->lock, so sk and chan locks are never held together. + * + * Since we cannot call l2cap_chan_close() without conn->lock, + * schedule l2cap_chan_timeout to close the channel; it already + * acquires conn->lock -> chan->lock in the correct order. */ while ((sk = bt_accept_dequeue(parent, NULL))) { struct l2cap_chan *chan; @@ -1454,14 +1458,12 @@ static void l2cap_sock_cleanup_listen(st state_to_string(chan->state)); l2cap_chan_lock(chan); - __clear_chan_timer(chan); - l2cap_chan_close(chan, ECONNRESET); - /* l2cap_conn_del() may already have killed this socket - * (it sets SOCK_DEAD); skip the duplicate to avoid a - * double sock_put()/l2cap_chan_put(). + /* Since we cannot call l2cap_chan_close() without + * conn->lock, schedule its timer to trigger the close + * and cleanup of this channel. */ - if (!sock_flag(sk, SOCK_DEAD)) - l2cap_sock_kill(sk); + if (chan->conn) + __set_chan_timer(chan, 0); l2cap_chan_unlock(chan); l2cap_chan_put(chan);