CVE-2026-98295 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: coredump: Quiesce dump work on unregister
hci_devcd_handle_pkt_init() arms dump_timeout and coredump producers queue dump_rx without holding an hdev reference. Unregister leaves both works live, so disconnecting during an active dump lets them access hdev after hci_release_dev() frees it.
Shut down coredump processing during unregister. Close the producer gate under dump_q.lock before disabling both works, then free the active buffer and queued packets under hci_dev_lock. Serializing the gate with enqueue prevents controller-specific workers from adding packets after the final purge.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/06/2026
The identified vulnerability resides within the Linux kernel Bluetooth subsystem, specifically affecting the coredump functionality associated with HCI device management. This issue manifests as a use-after-free condition triggered by improper synchronization during device unregistration. The root cause lies in the asynchronous nature of the dump work items and their interaction with the lifecycle of the underlying hardware device structure. When an HCI device is initialized via hci_devcd_handle_pkt_init, internal mechanisms arm a timeout for dumping data and allow coredump producers to queue packets without acquiring a reference count on the host controller device object. This design choice creates a race condition window where the software assumes the presence of valid memory structures that may no longer exist if the hardware is disconnected or removed while a dump operation is in progress.
The operational impact arises when an HCI device is unregistered, typically due to physical disconnection or driver removal. During this process, the kernel calls hci_release_dev to free the resources associated with the host controller structure. However, because the previously armed dump_timeout work and queued coredump packets were not properly quiesced before this deallocation occurs, they retain pointers to the now-freed memory region. If these asynchronous tasks are scheduled or executed after the device has been released, they attempt to dereference invalid pointers. This leads to kernel panics, system instability, or potentially exploitable conditions where an attacker with local access could trigger a denial of service by rapidly connecting and disconnecting Bluetooth devices during active data capture operations.
From a technical perspective, this flaw aligns with CWE-416, Use After Free, as the code accesses memory that has already been deallocated due to insufficient lifecycle management. The vulnerability also reflects weaknesses in concurrency control, specifically related to race conditions between asynchronous worker threads and device state transitions. In terms of threat modeling, this scenario can be mapped to MITRE ATT&CK techniques involving resource exhaustion or denial of service through kernel exploitation. An attacker could leverage this by inducing a high rate of Bluetooth connection events while simultaneously triggering coredump processes, thereby increasing the probability of hitting the race condition window before the system stabilizes after device removal.
The resolution implemented in the patch addresses these synchronization issues by enforcing strict serialization during the unregistration phase. The fix involves shutting down coredump processing explicitly when an HCI device is being removed. This is achieved by closing the producer gate under the dump_q.lock mutex, which prevents new packets from being added to the queue while existing ones are being purged. Subsequently, the active buffer and queued packets are freed under the protection of hci_dev_lock, ensuring that no controller-specific workers can inject data after the final cleanup sequence begins. This approach guarantees that all asynchronous operations complete or are safely aborted before any memory associated with the HCI device is released, thereby eliminating the possibility of accessing freed memory structures.
To mitigate similar vulnerabilities in broader systems development, it is critical to ensure that all asynchronous tasks related to a resource are properly quiesced and joined before releasing that resource's memory. Developers should always verify reference counting mechanisms when dealing with hardware abstractions where physical removal can occur independently of software state changes. Implementing robust locking strategies around state transitions, particularly during device teardown sequences, is essential for maintaining system integrity. Regular static analysis and dynamic testing focused on race conditions in driver code can help identify these synchronization gaps early in the development lifecycle, preventing potential kernel-level exploits that compromise system stability and security.