CVE-2026-68391

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

Both sides of the race are local: the vulnerable path is entered only by writing MGMT_OP_GET_CONN_INFO/MGMT_OP_GET_CLOCK_INFO to an AF_BLUETOOTH/BTPROTO_HCI socket bound to HCI_CHANNEL_CONTROL, and the free is driven by a local disconnect/device-teardown. A remote or adjacent Bluetooth peer cannot inject mgmt commands, so the vector is local even though the subsystem is Bluetooth.

AC:LAttack complexity, low

The attacker owns both sides of the race: one thread loops GET_CONN_INFO/GET_CLOCK_INFO, whose sync callback blocks in __hci_cmd_sync waiting on the controller for up to HCI_CMD_TIMEOUT, while another issues MGMT_OP_DISCONNECT or HCIDEVDOWN to free the hci_conn inside that wide window; with an emulated controller the response timing is fully controlled, and the sequence can be retried indefinitely.

PR:LPrivileges required, low

The opcodes lack HCI_MGMT_UNTRUSTED so they need a trusted mgmt socket (CAP_NET_ADMIN), which kernel CNA practice for the Bluetooth mgmt interface treats as low privilege: it is a delegable capability held by the non-root bluetoothd service account and Android's sandboxed Bluetooth process rather than full init-namespace root.

UI:NUser interaction, none

The attacker performs every step itself — queueing the mgmt command and tearing down the connection or the HCI index — with no victim action, pairing, or user-initiated Bluetooth operation required.

S:UScope, unchanged

The use-after-free and the resulting heap corruption stay entirely within the kernel's own security authority; no VM, IOMMU, or sandbox boundary is crossed.

C:HConfidentiality impact, high

get_conn_info_complete()/get_clock_info_complete() read rssi, tx_power, max_tx_power, clock and clock_accuracy from a freed hci_conn and return them to userspace over the mgmt socket; hci_conn comes from a general-purpose kmalloc cache, so grooming the reclaimed slab turns this into a repeatable kernel-memory disclosure oracle.

I:HIntegrity impact, high

The dangling cmd->user_data points at a freed, sprayable struct-device-embedded object that can be reclaimed with attacker-shaped data and is later put/released, and the unlocked lookup also propagates a stale conn->handle into hci_read_rssi_sync/hci_read_clock_sync so the host acts on a handle that may have been reused by another link — sufficient for controlled corruption after heap grooming.

A:HAvailability impact, high

Dereferencing the freed hci_conn in the hci_cmd_sync completion callback is a slab use-after-free that produces a KASAN splat and can oops or panic the kernel when the slab has been returned to the page allocator, and it can be re-triggered in a loop for sustained denial of service.