Bluetooth: Serialize SMP remote OOB data access
Subsystems (3)
PATCH 1/1 Bluetooth: Serialize SMP remote OOB data access
build_pairing_cmd() looks up remote OOB data and copies its contents without holding hdev->lock, which serializes the list's writers. After SMP finds an entry, a concurrent management Remove Remote OOB Data command can unlink and free it before SMP reads its present flag or copies its random and confirmation values. Removal can also invalidate an entry while the lookup is still traversing the list.
KASAN reported:
BUG: KASAN: slab-use-after-free in build_pairing_cmd+0x948/0x9b0 Call Trace: build_pairing_cmd+0x948/0x9b0 smp_recv_cb+0x459f/0x8110 l2cap_recv_frame+0xf14/0x9190 l2cap_recv_acldata+0xa64/0xd40 hci_rx_work+0x4ca/0x730 Allocated by task 87: hci_add_remote_oob_data+0x11d/0x530 add_remote_oob_data+0x282/0x400 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 93: hci_remote_oob_data_clear+0x108/0x1c0 remove_remote_oob_data+0x198/0x220 hci_sock_sendmsg+0x1033/0x1ea0
Taking hdev->lock in build_pairing_cmd() would recurse for callers that already hold it and invert the device-to-L2CAP lock order on the receive path. Add a per-device remote_oob_lock instead, held across the SMP lookup and copies and by the add, remove and clear helpers. Cover initialization and in-place updates as well, so SMP cannot read partially initialized or updated OOB values. Release the mutex on allocation failure, preserving the existing error return.
The new critical sections acquire no device, connection or channel locks. Writers retain their existing hdev->lock protection, which continues to serialize the other readers without changing their locking or behavior.
--- include/net/bluetooth/hci_core.h | 1 + net/bluetooth/hci_core.c | 12 +++++++++++- net/bluetooth/smp.c | 2 ++ 3 files changed, 14 insertions(+), 1 deletion(-)
include/net/bluetooth/hci_core.h +1 -0
@@ -562,6 +562,7 @@ struct hci_dev {struct list_head link_keys;struct list_head long_term_keys;struct list_head identity_resolving_keys; +struct mutex remote_oob_lock;struct list_head remote_oob_data;struct list_head le_accept_list;struct list_head le_resolv_list;
net/bluetooth/hci_core.c +11 -1
@@ -1489,8 +1489,10 @@ int hci_remove_remote_oob_data(struct hci_dev *hdev, bdaddr_t *bdaddr,BT_DBG ("%s removing %pMR (%u)" , hdev->name, bdaddr, bdaddr_type); +mutex_lock (&hdev->remote_oob_lock);list_del (&data->list);kfree (data); +mutex_unlock (&hdev->remote_oob_lock);return 0 ; }
@@ -1499,10 +1501,12 @@ void hci_remote_oob_data_clear(struct hci_dev *hdev) {struct oob_data *data, *n; +mutex_lock (&hdev->remote_oob_lock);list_for_each_entry_safe (data, n, &hdev->remote_oob_data, list) {list_del (&data->list);kfree (data); } +mutex_unlock (&hdev->remote_oob_lock); } int hci_add_remote_oob_data(struct hci_dev *hdev, bdaddr_t *bdaddr,
@@ -1511,11 +1515,14 @@ int hci_add_remote_oob_data(struct hci_dev *hdev, bdaddr_t *bdaddr, {struct oob_data *data; +mutex_lock (&hdev->remote_oob_lock); data =hci_find_remote_oob_data (hdev, bdaddr, bdaddr_type);if (!data) { data =kmalloc_obj (*data); -if (!data) +if (!data) { +mutex_unlock (&hdev->remote_oob_lock);return -ENOMEM ; + }bacpy (&data->bdaddr, bdaddr); data->bdaddr_type = bdaddr_type;
@@ -1548,6 +1555,8 @@ int hci_add_remote_oob_data(struct hci_dev *hdev, bdaddr_t *bdaddr,BT_DBG ("%s for %pMR" , hdev->name, bdaddr); +mutex_unlock (&hdev->remote_oob_lock); +return 0 ; }
@@ -2485,6 +2494,7 @@ struct hci_dev *hci_alloc_dev_priv(int sizeof_priv)mutex_init (&hdev->lock);mutex_init (&hdev->req_lock);mutex_init (&hdev->mgmt_pending_lock); +mutex_init (&hdev->remote_oob_lock);ida_init (&hdev->unset_handle_ida);
net/bluetooth/smp.c +2 -0
@@ -662,6 +662,7 @@ static void build_pairing_cmd(struct l2cap_conn *conn,else bdaddr_type =BDADDR_LE_RANDOM ; +mutex_lock (&hdev->remote_oob_lock); oob_data =hci_find_remote_oob_data (hdev, &hcon->dst, bdaddr_type);if (oob_data && oob_data->present) {
@@ -672,6 +673,7 @@ static void build_pairing_cmd(struct l2cap_conn *conn,SMP_DBG ("OOB Remote Confirmation: %16phN" , smp->pcnf);SMP_DBG ("OOB Remote Random: %16phN" , smp->rr); } +mutex_unlock (&hdev->remote_oob_lock); }else { authreq &= ~SMP_AUTH_SC ;
Signature · 1 line
2.43.0
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/series/1174574/
---Test result---
Test Summary:
CheckPatch PASS 2.55 seconds VerifyFixes PASS 0.73 seconds VerifySignedoff PASS 0.61 seconds GitLint PASS 1.26 seconds SubjectPrefix PASS 0.09 seconds BuildKernel PASS 29.84 seconds CheckAllWarning PASS 32.51 seconds CheckSparse PASS 35.23 seconds BuildKernel32 PASS 28.10 seconds CheckKernelLLVM PASS 31.78 seconds TestRunnerSetup PASS 691.48 seconds TestRunner_l2cap-tester PASS 15.98 seconds TestRunner_iso-tester PASS 36.52 seconds TestRunner_bnep-tester PASS 2.86 seconds TestRunner_mgmt-tester PASS 59.37 seconds TestRunner_rfcomm-tester PASS 4.17 seconds TestRunner_sco-tester PASS 7.25 seconds TestRunner_ioctl-tester PASS 4.36 seconds TestRunner_mesh-tester FAIL 7.65 seconds TestRunner_smp-tester PASS 4.02 seconds TestRunner_userchan-tester PASS 2.90 seconds TestRunner_6lowpan-tester PASS 4.07 seconds IncrementalBuild PASS 25.50 seconds
Details
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 2.552 seconds Mesh - Send cancel - 2 Timed out 2.000 seconds
https://github.com/bluez/bluetooth-next/pull/828
---
Regards,
Linux Bluetooth
This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <[email protected]>:
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <[email protected]>:
Quoted 8 lines · On Sun, 27 Sep 2026 14:42:50 +0800 you wrote:
build_pairing_cmd()looks up remote OOB data and copies its contents without holdinghdev->lock, which serializes the list's writers. After SMP finds an entry, a concurrent management Remove Remote OOB Data command can unlink and free it before SMP reads its present flag or copies its random and confirmation values. Removal can also invalidate an entry while the lookup is still traversing the list.[...]
Here is the summary with links:
- Bluetooth: Serialize SMP remote OOB data access
https://git.kernel.org/bluetooth/bluetooth-next/c/81a2345f1984
You are awesome, thank you!
Signature · 2 lines
Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html