CVE-2024-58241

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

Triggering the vulnerable window requires initiating HCI device teardown (`hci_unregister_dev()`), reachable locally via `/dev/vhci` close, HCI ldisc detach, or adapter down/removal — an adjacent Bluetooth peer can influence HCI traffic but cannot cause device unregistration. All required primitives are local syscalls (open/write/close/ioctl on a device node and Bluetooth sockets).

AC:LAttack complexity, low

The attacker controls both sides of the race — it drives the unregister (closing the vhci fd) while concurrently feeding HCI packets/commands that re-queue `rx_work`/`cmd_work`/`error_reset` — and can retry the open/close cycle indefinitely to win it and to spray the freed `hci_dev` slab. The `cmd_timer`/`ncmd_timer` re-arm even occurs on the unregister path itself via `hci_dev_close_sync()`, requiring no external timing luck.

PR:LPrivileges required, low

No capability check exists anywhere on the path: `vhci_open()` performs no `capable()` test, so an unprivileged user granted the device node (containers, Android's bluetooth uid, permissive udev rules) can create and destroy HCI devices and inject HCI frames at will. This matches the PR:L assignment for the structurally identical `hci_unregister_dev` teardown UAF CVE-2025-38250.

UI:NUser interaction, none

The attacker performs both the device teardown and the concurrent work re-submission entirely from its own processes. No victim action or cooperation is needed.

S:UScope, unchanged

The corruption is confined to kernel slab memory and workqueue structures within the same kernel security authority. No VM, IOMMU, or sandbox boundary is crossed.

C:HConfidentiality impact, high

A work_struct/delayed_work embedded in the freed `hci_dev` is dereferenced after `kfree()`, and `__queue_work()` follows the stale `dwork->wq` pointer into a destroyed workqueue. Controlled reallocation of the freed object turns this into an arbitrary-read primitive and leaks kernel pointers/heap contents.

I:HIntegrity impact, high

The same use-after-free lets the attacker place controlled data in the reclaimed `hci_dev` slab so that the firing timer operates on attacker-supplied `workqueue_struct`/`pool_workqueue`/list pointers and work function pointers, yielding arbitrary write and control-flow hijack. Per kernel scoring guidance, a UAF exploitable for heap spraying is High integrity impact.

A:HAvailability impact, high

Even unexploited, the stale timer queuing onto a destroyed workqueue causes a KASAN slab-use-after-free oops and kernel panic, and `destroy_workqueue()` with still-pending work triggers a WARN and leaves the workqueue broken. Re-queued `error_reset` additionally reintroduces the `destroy_workqueue()` self-flush deadlock that hangs the req_workqueue.