CVE-2021-47038 - Linux Kernel Vulnerability in Bluetooth: Avoid Deadlock between hci_dev->lock and Socket Lock

The Linux kernel developers have recently resolved a vulnerability concerning a deadlock situation between hci_dev->lock and socket lock in the Bluetooth subsystem. This vulnerability has been assigned the CVE identifier CVE-2021-47038.

The issue stems from the commit eab2404ba798 ("Bluetooth: Add BT_PHY socket option"), which added a dependency between the socket lock and hci_dev->lock that could lead to a deadlock. It was discovered that the function hci_conn_get_phy() does not rely on hdev being immutable during its runtime or even look at any of the members of hdev. Therefore, there is no need to hold that lock.

This fix prevents the lockdep splat shown below

WARNING: possible circular locking dependency detected
5.12.-rc1-00026-g73d464503354 #10 Not tainted
bluetoothd/1118 is trying to acquire lock:
ffff8f078383c078 (&hdev->lock){+.+.}-{3:3}, at: hci_conn_get_phy+x1c/x150 [bluetooth]

A thorough analysis of the code has led to the following conclusion on the existing dependency chain (in reverse order):

-> #3 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{:}:
   lock_sock_nested+x72/xa
   l2cap_sock_ready_cb+x18/x70 [bluetooth]
   l2cap_config_rsp+x27a/x520 [bluetooth]
   l2cap_sig_channel+x658/x133 [bluetooth]
   l2cap_recv_frame+x1ba/x310 [bluetooth]
   hci_rx_work+x1cc/x640 [bluetooth]
   process_one_work+x244/x5f
   worker_thread+x3c/x380
   kthread+x13e/x160
   ret_from_fork+x22/x30

-> #2 (&chan->lock#2/1){+.+.}-{3:3}:
   __mutex_lock+xa3/xa10
   l2cap_chan_connect+x33a/x940 [bluetooth]
   l2cap_sock_connect+x141/x2a [bluetooth]
   __sys_connect+x9b/xc
   __x64_sys_connect+x16/x20
   do_syscall_64+x33/x80
   entry_SYSCALL_64_after_hwframe+x44/xae

-> #1 (&conn->chan_lock){+.+.}-{3:3}:
   __mutex_lock+xa3/xa10
   l2cap_chan_connect+x322/x940 [bluetooth]
   l2cap_sock_connect+x141/x2a [bluetooth]
   __sys_connect+x9b/xc
   __x64_sys_connect+x16/x20
   do_syscall_64+x33/x80
   entry_SYSCALL_64_after_hwframe+x44/xae

-> # (&hdev->lock){+.+.}-{3:3}:
   __lock_acquire+x147a/x1a50
   lock_acquire+x277/x3d
   __mutex_lock+xa3/xa10
   hci_conn_get_phy+x1c/x150 [bluetooth]
   l2cap_sock_getsockopt+x5a9/x610 [bluetooth]
   __sys_getsockopt+xcc/x200
   __x64_sys_getsockopt+x20/x30
   do_syscall_64+x33/x80
   entry_SYSCALL_64_after_hwframe+x44/xae

Based on this analysis, it is evident that a possible unsafe locking scenario might involve the following sequence of events:

CPU                    CPU1
lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
                         lock(&chan->lock#2/1);
                         lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
lock(&hdev->lock);

* DEADLOCK *

The fix for this vulnerability has been deployed in the Linux kernel, and affected users are advised to upgrade to the latest version of the kernel. To learn more about this vulnerability, please refer to the original commit message: Linux Kernel Commit eab2404ba798.

In conclusion, the recent fix in the Linux kernel for CVE-2021-47038 eliminates the deadlock situation between hci_dev->lock and socket lock in the Bluetooth subsystem, thus improving system reliability and preventing potential problems.

Timeline

Published on: 02/28/2024 09:15:39 UTC
Last modified on: 12/06/2024 20:56:10 UTC