Re: [PATCH RESEND 0/1] Bluetooth: msft: fix vendor event use-after-free during open

Hi Ren,

On Fri, Aug 7, 2026 at 1:14 PM Ren Wei <[email protected]> wrote:
>
> From: Yong Wang <[email protected]>
>
> Hi Linux kernel maintainers,
>
> We found and validated a use-after-free in net/bluetooth/msft.c.
> The bug is reachable by root on systems exposing /dev/vhci and the
> Bluetooth debugfs controls. We tested the fix with the original
> reproducer and verified that it no longer crashes the guest. We also
> verified that the existing MSFT monitor functionality still works in
> the same setup.
>
> We provide the technical details and the reproducer below.
>
> ---- details below ----
>
> Bug details:
>
> Commit 5031ffcc79b8 ("Bluetooth: Keep MSFT ext info throughout a
> hci_dev's life cycle") changed msft_do_open() to reuse the live
> hdev->msft_data object across power cycles.
>
> That makes msft_do_open() free and replace msft->evt_prefix while the
> MSFT extension is already published through hdev->msft_data. On failure
> it can also clear hdev->msft_data and free the whole msft object.
>
> At the same time, msft_vendor_evt() reads hdev->msft_data and checks
> msft->evt_prefix_len / msft->evt_prefix before taking hci_dev_lock().
> Since HCI vendor events may still be processed while HCI_INIT is set,
> vendor event handling can race with msft_do_open() and hit a use-after-
> free on the old prefix buffer or the msft_data object itself.
>
> We reproduced the bug with a vhci-based setup that emulates a LE-only
> controller, enables the MSFT opcode through debugfs, seeds a large event
> prefix, and then sprays vendor events across the LE Set Event Mask ->
> msft_do_open() transition while repeatedly power-cycling the device.
> The crash we observed was a KASAN slab-use-after-free in memcmp() from
> msft_vendor_evt(), running on hci_rx_work.
>
> The reproducer requires python3, /dev/vhci and Bluetooth debugfs.

vhci requires root:

> btvirt -l1
Bluetooth emulator ver 5.87
Failed to open Virtual HCI device

> Reproducer:
>
>     cp poc.sh /root/poc.sh
>     chmod +x /root/poc.sh
>     ATTEMPTS=400 POC_TIMEOUT=180 /root/poc.sh
>
> We run the PoC in a 2 vCPU, 2 GB RAM x86 QEMU environment.

A general note: if root access is required, it is not a vulnerability
in the Bluetooth subsystem anymore. We should obviously harden it, but
generally, we shouldn't accept it as a weakness in the Bluetooth stack
if it requires emulating HCI traffic via vhci.