CVE-2026-98632 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: mgmt: Dequeue pending mesh_send_sync entries on cancel
In send_cancel(), pending mesh_tx objects are removed from the hdev->mesh_pending list and freed via mesh_send_complete(). However, if a mesh transmission was already queued onto hdev->cmd_sync_work_list via mesh_next(), the queued entry retains a raw pointer to mesh_tx.
When hci_cmd_sync_work later processes the entry, it attempts to execute mesh_send_sync and its destroy callback mesh_send_start_complete using the already freed mesh_tx pointer, leading to a use-after-free.
Fix this by invoking hci_cmd_sync_dequeue() for mesh_send_sync on the target mesh_tx before completing it. If the entry is found and dequeued, its destroy callback will complete and free the object; otherwise, mesh_send_complete() is called directly.
Additionally, ensure the transmission queue advances after cancellation or errors. In mesh_send_start_complete(), call mesh_next() on error unless err is -ECANCELED, because hci_cmd_sync_dequeue() holds hdev->cmd_sync_work_lock and calling mesh_next() synchronously would deadlock. Instead, advance the queue in send_cancel() once the lock is released and if no transmission is in progress.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel Bluetooth subsystem contains a critical use-after-free vulnerability within its Mesh networking implementation, specifically involving the management interface's handling of synchronous mesh transmissions. This flaw arises from an inconsistency in how pending command structures are managed when a transmission is canceled or fails. The core issue lies in the interaction between the immediate cancellation logic and the asynchronous work queue processing mechanism. When a cancel operation is initiated via send_cancel(), the system removes pending mesh_tx objects from the hdev->mesh_pending list and proceeds to free them by invoking mesh_send_complete(). However, this cleanup process does not account for entries that have already been queued onto the hdev->cmd_sync_work_list through the mesh_next() function. These queued entries retain raw pointers to the mesh_tx structures even after those structures have been deallocated in memory.
The operational impact of this vulnerability is severe, as it leads to a use-after-free condition when the kernel's command synchronization worker thread attempts to process these stale queue entries. Specifically, hci_cmd_sync_work iterates through the cmd_sync_work_list and attempts to execute mesh_send_sync along with its associated destroy callback, mesh_send_start_complete. Because the underlying mesh_tx object has already been freed by the cancellation routine, any access to this memory results in undefined behavior. This can lead to kernel panics, data corruption, or potentially allow an attacker to exploit the dangling pointer for arbitrary code execution if they can influence the contents of the freed memory region before it is reallocated for other purposes. The vulnerability highlights a race condition and logic error where lifecycle management of asynchronous tasks does not properly synchronize with immediate cancellation requests.
To resolve this issue, the fix involves ensuring that pending mesh_send_sync entries are explicitly dequeued from the command synchronization work list before they are completed or freed. This is achieved by invoking hci_cmd_sync_dequeue() for the target mesh_tx object prior to calling its completion routine. If the entry is successfully found and removed from the queue, its destroy callback will execute properly, ensuring safe cleanup of resources. If the entry is not present in the queue because it was already processed or never queued, mesh_send_complete() is called directly to handle the state transition. This approach guarantees that no dangling pointers remain accessible to the asynchronous worker thread, thereby eliminating the use-after-free condition at its source.
Furthermore, the patch addresses a secondary logic flaw regarding the advancement of the transmission queue following cancellation or error conditions. In scenarios where mesh_send_start_complete encounters an error other than -ECANCELED, it must ensure that the next item in the sequence is prepared for processing by calling mesh_next(). However, because hci_cmd_sync_dequeue() holds the hdev->cmd_sync_work_lock, invoking mesh_next() synchronously within this context would cause a deadlock due to lock reentrancy issues. To mitigate this, the logic was adjusted so that queue advancement occurs in send_cancel() only after the lock has been released and provided no transmission is currently in progress. This ensures proper sequencing of Mesh protocol messages without introducing concurrency hazards or resource contention errors.
From a classification perspective, this vulnerability aligns with CWE-416, Use After Free, as it involves accessing memory that has already been freed by another part of the system. The exploitation vector relates to improper synchronization and lifecycle management of kernel objects, which can be categorized under ATT&CK techniques related to privilege escalation or denial of service depending on the outcome of the exploit attempt. Mitigation strategies primarily involve applying the provided kernel patch to ensure proper dequeuing and lock handling. System administrators should monitor for stability issues in Bluetooth Mesh functionality and apply security updates promptly to prevent potential exploitation by local attackers who might trigger cancellation sequences during active mesh operations.