CVE-2021-47038: Vulnerability in Linux Linux

Severity: mediumType: vulnerabilityCVE-2021-47038

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: avoid deadlock between hci_dev->lock and socket lock Commit eab2404ba798 ("Bluetooth: Add BT_PHY socket option") added a dependency between socket lock and hci_dev->lock that could lead to deadlock. It turns out that hci_conn_get_phy() is not in any way relying on hdev being immutable during the runtime of this function, neither does it even look at any of the members of hdev, and as such there is no need to hold that lock. This fixes the lockdep splat below: ====================================================== WARNING: possible circular locking dependency detected 5.12.0-rc1-00026-g73d464503354 #10 Not tainted ------------------------------------------------------ bluetoothd/1118 is trying to acquire lock: ffff8f078383c078 (&hdev->lock){+.+.}-{3:3}, at: hci_conn_get_phy+0x1c/0x150 [bluetooth] but task is already holding lock: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}: lock_sock_nested+0x72/0xa0 l2cap_sock_ready_cb+0x18/0x70 [bluetooth] l2cap_config_rsp+0x27a/0x520 [bluetooth] l2cap_sig_channel+0x658/0x1330 [bluetooth] l2cap_recv_frame+0x1ba/0x310 [bluetooth] hci_rx_work+0x1cc/0x640 [bluetooth] process_one_work+0x244/0x5f0 worker_thread+0x3c/0x380 kthread+0x13e/0x160 ret_from_fork+0x22/0x30 -> #2 (&chan->lock#2/1){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x33a/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #1 (&conn->chan_lock){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x322/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (&hdev->lock){+.+.}-{3:3}: __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 __mutex_lock+0xa3/0xa10 hci_conn_get_phy+0x1c/0x150 [bluetooth] l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth] __sys_getsockopt+0xcc/0x200 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: &hdev->lock --> &chan->lock#2/1 --> sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&chan->lock#2/1); lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&hdev->lock); *** DEADLOCK *** 1 lock held by bluetoothd/1118: #0: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 [bluetooth] stack backtrace: CPU: 3 PID: 1118 Comm: bluetoothd Not tainted 5.12.0-rc1-00026-g73d464503354 #10 Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017 Call Trace: dump_stack+0x7f/0xa1 check_noncircular+0x105/0x120 ? __lock_acquire+0x147a/0x1a50 __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? __lock_acquire+0x2e1/0x1a50 ? lock_is_held_type+0xb4/0x120 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] __mutex_lock+0xa3/0xa10 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? lock_acquire+0x277/0x3d0 ? mark_held_locks+0x49/0x70 ? mark_held_locks+0x49/0x70 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] hci_conn_get_phy+0x ---truncated---

AI Analysis

Technical Summary

CVE-2021-47038 is a concurrency vulnerability in the Linux kernel's Bluetooth subsystem that can lead to a deadlock condition. The issue arises from a circular locking dependency introduced by commit eab2404ba798, which added a new Bluetooth PHY socket option. Specifically, the deadlock occurs between the hci_dev->lock and the socket lock (sk_lock) used in the Bluetooth L2CAP protocol implementation. The function hci_conn_get_phy() was incorrectly holding the hdev lock unnecessarily, despite not requiring the hdev structure to be immutable during its execution. This improper locking order creates a circular dependency chain involving multiple locks: hdev->lock, chan->lock, and sk_lock. When multiple CPUs or threads attempt to acquire these locks in conflicting orders, the system can deadlock, causing the Bluetooth daemon (bluetoothd) or other kernel threads to hang indefinitely. The deadlock manifests as a kernel warning about circular locking dependencies and can severely impact Bluetooth functionality. The vulnerability affects Linux kernel versions containing the problematic commit and was resolved by removing the unnecessary hdev lock acquisition in hci_conn_get_phy(). There are no known exploits in the wild, and no CVSS score has been assigned. The vulnerability is primarily a denial-of-service (DoS) risk due to system hangs or Bluetooth service unavailability rather than a direct confidentiality or integrity compromise.

Potential Impact

For European organizations, this vulnerability poses a risk primarily to systems relying on Linux-based Bluetooth functionality, including desktops, laptops, embedded devices, and IoT equipment. The deadlock can cause Bluetooth services to freeze, leading to denial of service for applications dependent on Bluetooth connectivity such as wireless peripherals, industrial sensors, medical devices, and communication tools. In sectors like manufacturing, healthcare, and critical infrastructure where Bluetooth-enabled devices are common, this could disrupt operations or delay critical workflows. While it does not directly expose data or allow privilege escalation, the resulting service outages could degrade productivity and availability. Organizations with large Linux deployments or those using custom Bluetooth stacks are particularly at risk. The absence of known exploits reduces immediate threat but the vulnerability should be addressed proactively to avoid potential future exploitation or accidental system hangs.

Mitigation Recommendations

To mitigate this vulnerability, European organizations should: 1) Apply the official Linux kernel patches that remove the unnecessary hdev lock in hci_conn_get_phy(), ensuring the kernel version is updated beyond the affected commit. 2) For environments where immediate patching is challenging, consider disabling Bluetooth services temporarily or restricting Bluetooth usage to reduce exposure. 3) Monitor system logs for kernel warnings related to circular locking dependencies or Bluetooth deadlocks to detect potential issues early. 4) Conduct thorough testing of Bluetooth functionality after kernel updates to confirm the deadlock is resolved. 5) For embedded or IoT devices using custom Linux kernels, coordinate with vendors or maintainers to integrate the fix promptly. 6) Implement robust system monitoring and automated reboot mechanisms to recover from potential deadlocks if they occur before patching. 7) Educate system administrators about this specific deadlock scenario to improve incident response and troubleshooting efficiency.