Re: [PATCH] Bluetooth: vhci: Flush suspend work after removing debugfs

[Chad Aldreda <ca@modelmiser.com>]

On Sun, 25 Oct 2026, Cen Zhang wrote:
> Runtime testing of this change was not performed.

The use-after-free in your report reproduces on mainline with the two
test-only delays below, and your patch removes it.

Tested on mainline d48723711bae (v7.4-rc1-672), whose hci_vhci.c and
hci_sync.c match bluetooth-next at 983f3fcb1282 (hci_core.c differs
only in rfkill handling), on x86_64 in QEMU (4 vCPUs) with KASAN,
lockdep, DEBUG_LIST, kmemleak and hung-task detection. A test program
opens /dev/vhci, answers every HCI command with a Command Complete,
brings the controller up with HCIDEVUP, then closes /dev/vhci while
another thread keeps toggling force_suspend in debugfs. One mode keeps
answering commands until close() returns; the other stops answering
before close().

Unaided the window is too narrow: 300 cycles in the answering mode on
the unpatched kernel gave no reports. Both kernels therefore carried
two test-only delays, not for merging:

  vhci_release():
  	cancel_delayed_work_sync(&data->open_timeout);
  	flush_work(&data->suspend_work);
  +	msleep(50);

  hci_suspend_dev():
  	hci_req_sync_unlock(hdev);
  +	msleep(200);
  	hci_clear_wake_reason(hdev);

With the delays and without your patch, 30 cycles in each mode gave
834 and 621 KASAN reports (kasan_multi_shot, so one bad close gives
many). Two objects are hit. The hci_dev is accessed after free from
hci_suspend_dev(), including the __mutex_lock() site in your report; it
is page-backed, so KASAN shows no free stack, and once the page is
reused the same accesses show up as slab-out-of-bounds against
unrelated slab objects. The vhci_data (kmalloc in vhci_open(), kfree in
vhci_release()) is read by vhci_suspend_work() and read and written by
process_one_work() after free, because suspend_work is embedded in it.
hci_resume_dev() was also reached, with an hdev pointer read from the
freed vhci_data, so it dereferenced an unrelated address.

With the delays and your patch, 160 cycles (130 answering, 30 not) had
no KASAN, lockdep, DEBUG_LIST, kmemleak or hung-task reports. Without
the delays, 150 cycles with the patch (answering mode) were also
clean; since the unpatched kernel was clean without them too, that run
only shows no regression. As expected, release can now also wait for
suspend or resume work that is already running, including an HCI
command timeout inside it, as the existing first flush_work() already
can.

Not tested: suspend with force_wakeup set, with connections, or with
scanning, advertising or discovery active (the controller was brought
up with HCIDEVUP and no bluetoothd, so hci_suspend_sync() had nothing
to pause), mgmt, real controllers or btvirt, module unload (Bluetooth
was built in), other architectures, and a build of bluetooth-next
itself (compared at source level only).

The harness and this report were produced with an AI assistant (Claude
Opus 5.5), which also did the earlier runs, including the unpatched
comparison. I ran the final version on the patched kernel myself and
got the same results. The harness is available on request.

Tested-by: Chad Aldreda <ca@modelmiser.com>