Re: [PATCH] Bluetooth: virtio_bt: unregister HCI device on open failure

From: Paul Menzel

Date: Wed Jun 24 2026 - 05:11:41 EST


Dear Haoxiang,


Thank you for your patch.

Am 24.06.26 um 10:43 schrieb Haoxiang Li:
virtbt_probe() registers the HCI device before calling
virtbt_open_vdev(). If opening the virtio Bluetooth
device fails, the error path frees the HCI device without
unregistering it.

Should you resend, please re-flow for 72/75 characters, so only three lines are used.

Fixes: dc65b4b0f90a ("Bluetooth: virtio_bt: fix device removal")
Cc: stable@xxxxxxxxxxxxxxx
Signed-off-by: Haoxiang Li <haoxiang_li2024@xxxxxxx>
---
drivers/bluetooth/virtio_bt.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/bluetooth/virtio_bt.c b/drivers/bluetooth/virtio_bt.c
index 140ab55c9fc5..bf6827431bb8 100644
--- a/drivers/bluetooth/virtio_bt.c
+++ b/drivers/bluetooth/virtio_bt.c
@@ -397,6 +397,7 @@ static int virtbt_probe(struct virtio_device *vdev)
return 0;
open_failed:
+ hci_unregister_dev(hdev);
hci_free_dev(hdev);
failed:
vdev->config->del_vqs(vdev);

Reviewed-by: Paul Menzel <pmenzel@xxxxxxxxxxxxx>


Kind regards,

Paul


PS: gemini/gemini-3.1-pro-preview found an unrelated issue to the patch during review of this patch [1].

This is a pre-existing issue, but does this error path safely clean up the
active virtqueues? Earlier in virtbt_probe(), virtio_device_ready(vdev) marks the device as
active. If virtbt_open_vdev() subsequently fails, the code jumps to the
open_failed label and eventually reaches here to call del_vqs(vdev).
Deleting virtqueues without calling virtio_reset_device(vdev) first violates
the VirtIO API contract for active devices. It could allow the host or
hypervisor to access guest memory that has already been freed by del_vqs(),
potentially leading to a use-after-free.
Should virtio_reset_device(vdev) be called before tearing down the
virtqueues in this error path?

No idea, how to best track these things.


[1]: https://sashiko.dev/#/patchset/20260624084333.2885144-1-haoxiang_li2024%40163.com