linux-kernel - [PATCH] Bluetooth: Perform careful capability checks in hci_sock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <tencent_2FAB909645504A5E0FDC88F125E139242C05@qq.com>
Date: Fri,  9 Jan 2026 01:57:18 +0000
From: Jerry Wu <w.7erry@...mail.com>
To: marcel@...tmann.org
Cc: johan.hedberg@...il.com,
	luiz.dentz@...il.com,
	linux-bluetooth@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	w.7erry@...mail.com
Subject: [PATCH] Bluetooth: Perform careful capability checks in hci_sock_bind()

Previously, the HCI_SOCK_TRUSTED flag was set in hci_sock_bind() by
checking capable(CAP_NET_ADMIN). This function verifies that the
current caller of the bind system call has the required capability.

However, this approach is vulnerable to a "confused deputy" attack. A
malicious unprivileged program can open an HCI socket and deliberately
share it with a privileged task (e.g., via file descriptor passing).
If the privileged task is tricked into calling bind() on that socket,
the capable() check will pass, and the socket will be marked as
trusted. The original unprivileged program then retains access to this
now-trusted socket, allowing it to perform privileged operations.

This issue mirrors the vulnerability previously identified and fixed
in hci_sock_ioctl().

Fix this by using sk_capable() instead of capable(). This ensures that
both the task performing the bind and the socket opener must have the
CAP_NET_ADMIN capability before the socket is granted the
HCI_SOCK_TRUSTED status.

Fixes: f4cdbb3f25c1 ("Bluetooth: Handle HCI raw socket transition from unbound to bound")
Signed-off-by: Jerry Wu <w.7erry@...mail.com>
---
Commit 25c150ac103a ("bluetooth: Perform careful capability checks in hci_sock_ioctl()")
fixed CVE-2023-2002. hci_sock_bind contains a similar logic. Would it make sense to
fix it in the same way?

Thank you for spending time reading this. Apologies if I missed anything.

 net/bluetooth/hci_sock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index 4e7bf63af9c5..2bab2532dd9a 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -1259,7 +1259,7 @@ static int hci_sock_bind(struct socket *sock, struct sockaddr_unsized *addr,
 			}
 		}

-		if (capable(CAP_NET_ADMIN))
+		if (sk_capable(CAP_NET_ADMIN))
 			hci_sock_set_flag(sk, HCI_SOCK_TRUSTED);

 		hci_pi(sk)->hdev = hdev;
@@ -1427,7 +1427,7 @@ static int hci_sock_bind(struct socket *sock, struct sockaddr_unsized *addr,
 		 * untrusted users the interface is restricted and
 		 * also only untrusted events are sent.
 		 */
-		if (capable(CAP_NET_ADMIN))
+		if (sk_capable(CAP_NET_ADMIN))
 			hci_sock_set_flag(sk, HCI_SOCK_TRUSTED);

 		hci_pi(sk)->channel = haddr.hci_channel;
-- 
2.52.0