CVE-2026-98738 in Linux
Summary
by MITRE • 10/18/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/19/2026
This vulnerability represents a classic race condition within the Linux kernel Bluetooth subsystem, specifically affecting the Security Manager Protocol (SMP) implementation during the handling of Remote Out-of-Band data. The core technical flaw lies in the build_pairing_cmd function, which is responsible for retrieving remote OOB information to facilitate secure pairing processes. In its original state, this function accessed and copied sensitive cryptographic material from a shared list without acquiring the necessary synchronization primitives. Specifically, it failed to hold hdev->lock, which serves as the primary serialization mechanism for writers modifying that data structure. This oversight created a window of opportunity where concurrent operations could alter or destroy the data being read by SMP, leading to memory safety violations and potential system instability.
The operational impact of this flaw is severe, manifesting primarily as use-after-free errors detected via Kernel Address Sanitizer (KASAN). When an entry in the OOB list is identified for pairing, a concurrent management command can trigger the removal or clearing of that same remote OOB data. This action unlinks and frees the memory associated with the entry before SMP has finished reading its present flag or copying the random and confirmation values required for authentication. Furthermore, if the removal occurs while the lookup traversal is still in progress, it invalidates pointers being used by the current operation. These race conditions can lead to kernel panics, denial of service through system crashes, or potentially more sophisticated exploitation vectors where an attacker might leverage corrupted memory states to execute arbitrary code, although the primary observed effect is stability degradation via slab-use-after-free bugs.
From a vulnerability classification perspective, this issue aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, commonly known as a race condition. The specific manifestation of accessing freed memory corresponds directly to CWE-416: Use After Free. In the context of the MITRE ATT&CK framework for enterprise security, such kernel-level vulnerabilities often fall under techniques related to privilege escalation or defense evasion if exploited successfully, though they are primarily categorized under initial access vectors that target system stability and integrity. The lack of proper locking allows an attacker with local access to trigger these race conditions through crafted Bluetooth management commands, potentially escalating privileges by crashing the kernel or exploiting memory corruption states.
The resolution involves a structural change to the locking mechanism within the Bluetooth stack rather than simply adding locks around existing critical sections which could cause deadlocks due to lock ordering issues. The developers introduced a dedicated per-device remote_oob_lock mutex that is held across SMP lookups, data copies, and by all helper functions responsible for adding, removing, or clearing OOB data. This ensures mutual exclusion during both read and write operations on the OOB list. Crucially, this new lock covers initialization and in-place updates to prevent SMP from reading partially initialized values. The implementation carefully avoids holding device, connection, or channel locks within these critical sections to prevent recursion issues and maintain existing lock ordering hierarchies that writers retain through hdev->lock. This approach preserves the integrity of concurrent operations while eliminating the race window without introducing new deadlock scenarios.
Mitigation strategies for this vulnerability involve ensuring systems are updated with kernel patches that include the fix for Bluetooth SMP OOB data serialization. For environments where immediate patching is not feasible, restricting access to Bluetooth management sockets can reduce exposure, as the exploit requires triggering specific HCI socket messages. Additionally, monitoring system logs for KASAN reports or unexpected Bluetooth disconnections and crashes can help identify potential exploitation attempts in real-time. Security teams should prioritize applying kernel updates that address this race condition to maintain the integrity of secure pairing mechanisms and prevent memory corruption vulnerabilities within the network stack.