---
id: "CVE-2026-98737"
kind: "vulnerability"
aliases: ["CVE-2026-98737"]
title: "Linux kernel Bluetooth: inquiry cache use-after-free can crash or corrupt memory"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["bluetooth", "linux-kernel", "package", "self-hosted"]
not_affected_if: ["bluetooth-module-not-loaded", "no-bluetooth-hardware"]
published_at: "2026-10-18T16:17:27+00:00"
first_seen_at: "2026-10-23T21:57:16+00:00"
updated_at: "2026-10-25T05:17:09+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98737", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux kernel Bluetooth: inquiry cache use-after-free can crash or corrupt memory

A race in the Linux kernel Bluetooth HCI code lets the inquiry cache be flushed while a sync worker still reads a freed entry. The sources describe a use-after-free that KASAN caught, and do not state what an attacker can achieve beyond that.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` and compare against the fixed kernel builds listed in the NVD entry
- `lsmod | grep -i bluetooth` to see whether the Bluetooth stack is loaded at all

## Fix

- Update the Linux kernel to a build that includes the upstream fix for CVE-2026-98737 (the version is unknown from the sources)
- Until patched, unloading the Bluetooth modules (`modprobe -r bluetooth`) on hosts that do not need Bluetooth removes the exposed code path

## Timeline

- 2026-10-23T21:57:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98737

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_sync: Fix inquiry cache use-after-free

The sync command worker holds hdev->req_lock, but inquiry-cache updates
and flushes use hdev->lock. Both hci_acl_create_conn_sync() and
hci_stop_discovery_sync() look up entries and read their fields without
taking hdev->lock.

After either lookup returns, a concurrent HCIINQUIRY ioctl can acquire
hdev->lock and flush the cache, freeing the entry. The worker then reads
the freed entry while preparing a create-connection or remote-name-cancel
command. The list traversal also races with cache updates and removal.

KASAN reported these accesses:

  BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5f1/0x650
  Workqueue: hci0 hci_cmd_sync_work
  Call Trace:
   hci_acl_create_conn_sync+0x5f1/0x650
   hci_cmd_sync_work+0x13c/0x290

  Allocated by task 90:
   hci_inquiry_cache_update+0x3e6/0x7d0
   hci_inquiry_result_evt+0x3cb/0x560

  Freed by task 93:
   hci_inquiry_cache_flush+0x111/0x2b0
   hci_inquiry+0x2f2/0x780
   hci_sock_ioctl+0x269/0x5f0

  BUG: KASAN: slab-use-after-free in hci_stop_discovery_sync+0x3b1/0x3c0
  Workqueue: hci0 hci_cmd_sync_work
  Call Trace:
   hci_stop_discovery_sync+0x3b1/0x3c0
   hci_cmd_sync_work+0x173/0x300

  Allocated by task 86:
   hci_inquiry_cache_update+0x483/0x940
   hci_inquiry_result_evt+0x3cb/0x560

  Freed by task 91:
   hci_inquiry_cache_flush+0x13e/0x2f0
   hci_inquiry+0x2f2/0x780
   hci_sock_ioctl+0x269/0x5f0

Hold hdev->lock across each lookup and all reads from its result. Copy the
remote address before unlocking so discovery cancellation does not retain
a cache entry pointer. Release the lock before sending synchronous HCI
commands, since their completion handlers may need the same lock.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_