CVE-2026-98632: Bluetooth: mgmt: Dequeue pending mesh_send_sync entries on cancel
Bluetooth: mgmt: Dequeue pending meshsendsync entries on cancel
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
azurelinux/kernelto a version that resolves this vulnerability.Fixed in 6.6.159.1-1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.189 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.158 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.112 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.55 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.9 - Compensating control
Update Bluetooth mgmt mesh transmission cancellation handling to invoke hci_cmd_sync_dequeue() for mesh_send_sync on the target mesh_tx before completing it; advance the queue in send_cancel() after releasing the lock when no transmission is in progress; and call mesh_next() from mesh_send_start_complete() on errors except -ECANCELED.
Event History
Frequently Asked Questions
Which execution path must be present for the use-after-free to occur?
A Bluetooth mesh transmission must have been queued on hdev->cmd_sync_work_list by mesh_next(), then cancelled while its mesh_tx object is still referenced by that queued synchronous command entry. Later processing of that entry can invoke callbacks using the freed object.
What does the fix do when a mesh transmission is cancelled?
It attempts to dequeue the pending mesh_send_sync entry for the target transmission before completing it. If the entry was dequeued, its destroy callback completes and frees the object; otherwise, mesh_send_complete() is called directly, and the transmission queue is advanced after cancellation or applicable errors.