Cloudanix VulnDB

CVE-2026-98738

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing flaw in Linux Bluetooth pairing data handling can let an attacker crash the system or gain elevated access by racing two operations against each other.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in Bluetooth SMP when build_pairing_cmd performs unlocked lookup and copy of remote OOB data entries while concurrent management remove commands unlink and free them via the hdev list.

Why it matters to the business

Kernel memory corruption or crash on Linux systems using Bluetooth during pairing, risking denial of service or local privilege escalation on devices with the vulnerable stack.

How an attack unfolds

An attacker with local or adjacent Bluetooth access sends SMP frames to invoke build_pairing_cmd while simultaneously issuing management commands that add and remove OOB data, racing the free with the read of present flag, random, and confirmation values.

How to fix it

Update the Linux kernel to the version containing the remote_oob_lock mutex that serializes SMP lookups with add, remove, and clear helpers while preserving existing hdev lock behavior.

How to confirm the fix worked

Confirm the new mutex is acquired around OOB lookup/copy and initialization paths; re-test concurrent SMP and management operations for absence of KASAN slab-use-after-free reports.

Typical attack path

  1. Trigger SMP receive path via l2cap_recv_frame to reach build_pairing_cmd
  2. Concurrently call remove_remote_oob_data through hci_sock_sendmsg to free the OOB entry
  3. Access the now-freed slab object during list traversal or value copy

How to detect it

Scan kernel logs for KASAN slab-use-after-free reports citing build_pairing_cmd, smp_recv_cb, and hci_remote_oob_data_clear; correlate with Bluetooth pairing or management socket activity.

  • BUG: KASAN: slab-use-after-free in build_pairing_cmd
  • build_pairing_cmd+0x948/0x9b0
  • hci_remote_oob_data_clear+0x108/0x1c0

What your security team should do

  • Apply the fixing kernel update on all Bluetooth-enabled Linux hosts within the next maintenance window
  • Disable Bluetooth radios where pairing is unnecessary
  • Enable kernel hardening features such as KASAN in test environments to catch similar races

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Serialize SMP remote OOB data access build_pairing_cmd() looks up remote OOB data and copies its contents without holding hdev->lock, which serializes the list's writers. After SMP finds an entry, a concurrent management Remove Remote OOB Data command can unlink and free it before SMP reads its present flag or copies its random and confirmation values. Removal can also invalidate an entry while the lookup is still traversing the list. KASAN reported: BUG: KASAN: slab-use-after-free in build_pairing_cmd+0x948/0x9b0 Call Trace: build_pairing_cmd+0x948/0x9b0 smp_recv_cb+0x459f/0x8110 l2cap_recv_frame+0xf14/0x9190 l2cap_recv_acldata+0xa64/0xd40 hci_rx_work+0x4ca/0x730 Allocated by task 87: hci_add_remote_oob_data+0x11d/0x530 add_remote_oob_data+0x282/0x400 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 93: hci_remote_oob_data_clear+0x108/0x1c0 remove_remote_oob_data+0x198/0x220 hci_sock_sendmsg+0x1033/0x1ea0 Taking hdev->lock in build_pairing_cmd() would recurse for callers that already hold it and invert the device-to-L2CAP lock order on the receive path. Add a per-device remote_oob_lock instead, held across the SMP lookup and copies and by the add, remove and clear helpers. Cover initialization and in-place updates as well, so SMP cannot read partially initialized or updated OOB values. Release the mutex on allocation failure, preserving the existing error return. The new critical sections acquire no device, connection or channel locks. Writers retain their existing hdev->lock protection, which continues to serialize the other readers without changing their locking or behavior.

Affected packages

Ecosystem Package Introduced Fixed