CVE-2026-98295

What it actually does

Use-after-free in Linux kernel Bluetooth coredump: hci_devcd_handle_pkt_init arms dump_timeout and dump_rx work without holding hdev reference; hci_unregister_dev leaves the works running so they can dereference freed hdev after hci_release_dev.

Why it matters to the business

Kernel memory corruption or crash on Linux Bluetooth devices when a controller disconnects while a coredump is active; may lead to denial of service or local privilege escalation.

How an attack unfolds

An attacker with local access triggers a Bluetooth controller disconnect during an active coredump, causing queued timeout or RX work items to access the already-freed hci_dev structure.

How to fix it

Apply the upstream patch that shuts down coredump processing in hci_unregister_dev: close the producer gate under dump_q.lock, cancel both works, and purge buffers under hci_dev_lock. Rebuild and deploy the fixed kernel.

How to confirm the fix worked

Confirm the patch is present by inspecting net/bluetooth/hci_core.c for the new gate-closing and work-cancel logic in hci_unregister_dev; test by exercising Bluetooth register/unregister cycles with concurrent coredump attempts.

Typical attack path

1. Obtain local access to a Linux system with Bluetooth enabled
2. Initiate or trigger a coredump on the HCI device
3. Force controller disconnection while dump works are pending
4. Work items dereference freed hdev leading to UAF

How to detect it

Search kernel logs for Bluetooth coredump-related oops, workqueue warnings, or use-after-free reports mentioning hci_dev; correlate with sudden HCI unregister events followed by crashes.

• hci_devcd_handle_pkt_init
• dump_timeout work on unregistered hdev
• hci_release_dev followed by Bluetooth work item access

What your security team should do

• Prioritize kernel upgrade on all systems exposing Bluetooth
• Disable Bluetooth where not required until patched
• Monitor for kernel oops or Bluetooth-related crashes indicating possible exploitation