Re: [PATCH] Bluetooth: vhci: Serialize packet reception with device creation

[Chad Aldreda <ca@modelmiser.com>]

On Sat, 24 Oct 2026, Cen Zhang wrote:
> An incoming packet write can overlap the delayed default-create work
> scheduled by vhci_open(). If registration fails before acquiring the
> registration reference, the following order is possible:

The use-after-free reproduces on mainline without added delays, and
your patch removes it.

Tested on mainline v7.4-rc1-672-gd48723711bae, whose hci_vhci.c
matches bluetooth-next at 983f3fcb1282, on x86_64 in QEMU (4 vCPUs)
with KASAN, lockdep, DEBUG_LIST and kmemleak. A test program opens
/dev/vhci and creates the controller by writing the vendor packet
0xff 0x00, which runs __vhci_create_device() under open_mutex like the
default-create work (fail-nth is per task, so creation was driven from
the test thread rather than the delayed work). Fault injection
(failslab with ignore-gfp-wait=N, and fail-nth on the creating thread)
fails one allocation inside hci_register_dev(), so creation frees the
hci_dev it has already stored in data->hdev and returns -EBUSY.
Meanwhile a second thread keeps writing HCI event packets on the same
fd.

Without your patch, 300 cycles (295 with a failed registration) gave
42 KASAN reports: use-after-free reads at the same four sites in
hci_recv_frame() called from vhci_write(), 10 or 11 at each site. With
your patch, 300 cycles (296 failed registrations) gave none.

With two test-only delays, msleep(50) after "data->hdev = hdev;" and
msleep(100) at the start of hci_recv_frame(), every cycle with a
failed registration hits without the patch (39 cycles, 156 reports at
the same four sites; a verbose run shows each is an 8-byte read), at
both an early and a late allocation failure in hci_register_dev(). The
writer saw exactly 39 writes fail with an error other than -ENODEV, one
per failed registration (the errno itself was not recorded),
consistent with the HCI_UP/HCI_INIT test rejecting them. With the
patch and the same delays, 170 cycles (161 failed registrations) were
clean, and no write failed with anything but -ENODEV. These delayed
runs are the decisive comparison.

No lockdep, DEBUG_LIST, kmemleak or hung-task reports in any run with
the patch, so holding open_mutex across hci_recv_frame() caused no
lock-order report here; open_mutex has no other users in hci_vhci.c.

Not tested: the delayed default-create work itself (creation was
triggered by the vendor packet, which takes the same path under the
same mutex), registration failures other than injected allocation
failures, ACL, SCO or ISO packets (only event packets were written),
real controllers or btvirt, other architectures, and a build of
bluetooth-next itself (compared at source level only).

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

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