CVE-2026-68389

What it actually does

Use-after-free in hci_qca memdump handling: zero dump size frees qca_memdump without clearing the pointer or disabling collection/IBS state, allowing subsequent work items to dereference the freed object.

Why it matters to the business

Bluetooth-enabled Linux systems may experience kernel crashes, memory corruption, or local privilege escalation when a malicious or faulty Bluetooth controller sends an invalid memdump packet, disrupting wireless connectivity and potentially compromising the host.

How an attack unfolds

An attacker with the ability to send crafted HCI packets (via a compromised or rogue Bluetooth controller) triggers qca_controller_memdump with a zero-size report; the error path leaves stale pointers and flags, so a later scheduled memdump work item operates on freed memory, enabling use-after-free exploitation.

How to fix it

Update the Linux kernel to a version containing the fix that clears the saved pointer and memdump state before returning from the invalid-size path; rebuild and reboot systems using the hci_qca driver.

How to confirm the fix worked

Inspect kernel source for the corrected error path in drivers/bluetooth/hci_qca.c that matches the cleanup used on hci_devcd_init failure; confirm the patch is present via git log or package changelog and verify no dangling pointer remains on zero-size return.

Typical attack path

1. Attacker gains ability to inject HCI traffic or control a Bluetooth controller
2. Controller emits memdump sequence-zero packet advertising zero dump size
3. qca_controller_memdump frees the memdump object without clearing qca->qca_memdump or collection state
4. Subsequent memdump work item reads the dangling pointer and performs operations on freed memory
5. Attacker leverages the resulting use-after-free for memory corruption or code execution

How to detect it

Search kernel logs for hci_qca memdump error paths mentioning zero dump size or invalid memdump; look for Bluetooth stack crashes or use-after-free reports in dmesg around the time of suspicious HCI traffic.

What your security team should do

• Prioritize kernel updates on all systems exposing Bluetooth via the qca driver
• Disable Bluetooth where not required until patched
• Monitor vendor advisories for backported fixes in supported distributions