[PATCH] Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister

[PATCH] Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister

[Nguyen Ngoc Thang]

hci_unregister_dev() disables cmd_work and cmd_timer, then calls
hci_cmd_sync_clear(), whose cancel_work_sync() waits for
hci_cmd_sync_work() to return. That worker dequeues and runs every
entry on cmd_sync_work_list. With cmd_work disabled nothing reaches
the controller, so each queued HCI command waits the full
HCI_CMD_TIMEOUT (2s).

The backlog has no bound. Userspace can keep queuing MGMT commands
such as MGMT_OP_GET_CLOCK_INFO against a controller that doesn't
answer. Closing /dev/vhci then blocks in vhci_release() for
backlog * 2s:

  INFO: task syz-executor:5749 blocked for more than 143 seconds.
   cancel_work_sync
   hci_cmd_sync_clear
   hci_unregister_dev
   vhci_release

In a local reproduction the backlog held more than 5000 entries,
which comes to hours of hang.

Stop the worker from taking new entries once HCI_UNREGISTER is set,
and wake any request still waiting with -ENODEV before cancelling
the work. The entries left over are destroyed with -ECANCELED by the
existing sweep in hci_cmd_sync_clear(). They stay on the list until
the work has stopped, so hci_cmd_sync_dequeue() and friends still see
them. A callback already running may still issue another command,
which delays unregister by at most one timeout per remaining command,
not by the whole backlog.

Fixes: 008ee9eb8a11 ("Bluetooth: hci_sync: Fix not processing all entries on cmd_sync_work")
Reported-by: syzbot+217e3f1283cafe80586e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=217e3f1283cafe80586e
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
---
Notes (not for the changelog):

Two reproducers were tested on QEMU x86_64 with KASAN and PROVE_LOCKING,
on master @28c5139761e5 (v7.3-rc2-1134). The patch also applies cleanly
to bluetooth-next/master.

 - syzbot C repro (converted from the syz program): it loops on
   MGMT_OP_GET_CLOCK_INFO, which queues HCI_OP_READ_CLOCK.
 - The repro from the cause bisection: it emits LE Create BIG Complete
   events for an unknown BIG, and each event queues HCI_OP_LE_TERM_BIG.
   That queueing path is why the bisection landed on the ISO BIS commit.

Each run lets the repro go for N seconds, then SIGKILLs it and times
how long it takes to be reaped, i.e. how long vhci_release() takes.

  unpatched, both repros:  still blocked after more than 10 minutes,
                           hung-task reports every 20s, same lock
                           state as the syzbot report
  patched, both repros, N=8/30/60s:  reaped in 0-1s
  patched + debug print:   backlog of 2641 entries (N=30s) and 5260
                           entries (N=60s); hci_cmd_sync_clear() took
                           1-2ms

No KASAN, lockdep or hung-task reports on the patched kernel.

 net/bluetooth/hci_sync.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 74e2b04c84b2..e41fc1427d34 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -312,6 +312,10 @@ static void hci_cmd_sync_work(struct work_struct *work)
 	while (1) {
 		struct hci_cmd_sync_work_entry *entry;
 
+		/* Leave the backlog to hci_cmd_sync_clear() */
+		if (hci_dev_test_flag(hdev, HCI_UNREGISTER))
+			break;
+
 		mutex_lock(&hdev->cmd_sync_work_lock);
 		entry = list_first_entry_or_null(&hdev->cmd_sync_work_list,
 						 struct hci_cmd_sync_work_entry,
@@ -658,6 +662,8 @@ void hci_cmd_sync_clear(struct hci_dev *hdev)
 {
 	struct hci_cmd_sync_work_entry *entry, *tmp;
 
+	/* cmd_work is disabled, the pending request can only time out */
+	hci_cmd_sync_cancel_sync(hdev, ENODEV);
 	cancel_work_sync(&hdev->cmd_sync_work);
 	cancel_work_sync(&hdev->reenable_adv_work);
 
-- 
2.43.0

RE: Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

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/1174576/

---Test result---

Test Summary:
CheckPatch                    PASS      2.05 seconds
VerifyFixes                   PASS      0.11 seconds
VerifySignedoff               PASS      0.11 seconds
GitLint                       PASS      0.31 seconds
SubjectPrefix                 PASS      0.10 seconds
BuildKernel                   PASS      29.19 seconds
CheckAllWarning               PASS      33.76 seconds
CheckSparse                   PASS      36.00 seconds
BuildKernel32                 PASS      28.99 seconds
CheckKernelLLVM               PASS      32.20 seconds
TestRunnerSetup               PASS      736.85 seconds
TestRunner_l2cap-tester       PASS      12.36 seconds
TestRunner_iso-tester         PASS      12.57 seconds
TestRunner_bnep-tester        PASS      3.11 seconds
TestRunner_mgmt-tester        PASS      59.93 seconds
TestRunner_rfcomm-tester      PASS      4.45 seconds
TestRunner_sco-tester         PASS      5.56 seconds
TestRunner_ioctl-tester       PASS      4.64 seconds
TestRunner_mesh-tester        FAIL      7.83 seconds
TestRunner_smp-tester         PASS      4.33 seconds
TestRunner_userchan-tester    PASS      3.19 seconds
TestRunner_6lowpan-tester     PASS      4.37 seconds
IncrementalBuild              PASS      27.11 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.444 seconds
Mesh - Send cancel - 2                               Timed out    1.999 seconds


https://github.com/bluez/bluetooth-next/pull/830

---
Regards,
Linux Bluetooth

Re: [PATCH] Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister

[patchwork-bot+bluetooth]

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Sun, 27 Sep 2026 22:18:02 +0700 you wrote:
> hci_unregister_dev() disables cmd_work and cmd_timer, then calls
> hci_cmd_sync_clear(), whose cancel_work_sync() waits for
> hci_cmd_sync_work() to return. That worker dequeues and runs every
> entry on cmd_sync_work_list. With cmd_work disabled nothing reaches
> the controller, so each queued HCI command waits the full
> HCI_CMD_TIMEOUT (2s).
> 
> [...]

Here is the summary with links:
  - Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister
    https://git.kernel.org/bluetooth/bluetooth-next/c/b1f24c1ab523

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html