CVE-2026-31500: Linux Kernel Race Condition Vulnerability

CVE-2026-31500 Overview

CVE-2026-31500 is a race condition vulnerability in the Linux kernel's Bluetooth Intel driver (btintel) that can lead to a use-after-free condition. The vulnerability exists in the btintel_hw_error() function, which issues HCI commands without properly acquiring the hci_req_sync_lock, allowing concurrent access with the device close path in btintel_shutdown_combined(). When both code paths manipulate hdev->req_status and hdev->req_rsp concurrently, the close path may free the response skb first, causing the still-running hardware error recovery path to trigger a slab-use-after-free in kfree_skb().

Critical Impact

This race condition between the Bluetooth hardware error handler and device shutdown can result in kernel memory corruption, potentially leading to system instability, denial of service, or privilege escalation.

Affected Products

• Linux kernel systems with Intel Bluetooth adapters using the btintel driver
• Linux kernel versions prior to the security patches referenced in the kernel patch commits
• Systems running Bluetooth services with Intel wireless adapters

Discovery Timeline

• April 22, 2026 - CVE-2026-31500 published to NVD
• April 23, 2026 - Last updated in NVD database

Technical Details for CVE-2026-31500

Vulnerability Analysis

The vulnerability resides in the Bluetooth Intel driver's hardware error recovery mechanism. When a hardware error occurs, btintel_hw_error() executes two synchronous HCI commands: HCI_OP_RESET and Intel exception-info retrieval via __hci_cmd_sync(). The critical flaw is that these operations occur without holding hci_req_sync_lock, which is the lock designed to serialize synchronous HCI command operations.

This missing synchronization creates a time-of-check-time-of-use (TOCTOU) race window. When a device close operation (hci_dev_do_close()) is initiated concurrently, it calls btintel_shutdown_combined(), which properly acquires the lock before issuing its own __hci_cmd_sync() calls. However, the unserialized hardware error path can interleave with this operation, leading to shared state corruption.

The race manifests when both paths access hdev->req_rsp - the response buffer for synchronous HCI commands. The shutdown path frees this buffer while the hardware error path still holds a reference, resulting in a classic use-after-free scenario when kfree_skb() is subsequently called on the already-freed memory.

Root Cause

The root cause is missing lock acquisition in btintel_hw_error(). The function at drivers/bluetooth/btintel.c issues __hci_cmd_sync() calls without first acquiring hci_req_sync_lock, which is required for all synchronous HCI command issuers. This design oversight allows the hardware error recovery sequence to race against other HCI command paths, particularly the device shutdown sequence. The fix wraps the entire recovery sequence in hci_req_sync_lock/unlock calls to serialize it with all other synchronous HCI command issuers.

Attack Vector

The vulnerability requires local access to a system with Intel Bluetooth hardware. An attacker would need to trigger conditions that cause both a Bluetooth hardware error condition and a concurrent device close operation. While this may require precise timing, the race window can potentially be widened through various system stress techniques or by exploiting the hardware error injection capabilities available on some systems. The resulting use-after-free could be leveraged for kernel memory corruption, potentially leading to privilege escalation from a local unprivileged context.

The race condition is documented in the KASAN (Kernel Address Sanitizer) reports, which show the data race occurring between the kworker thread handling hci_error_reset and an ioctl call processing the device close operation, demonstrating the concurrent access pattern at net/bluetooth/hci_sync.c:199-200 and drivers/bluetooth/btintel.c:3648.

Detection Methods for CVE-2026-31500

Indicators of Compromise

• KASAN reports indicating slab-use-after-free in sk_skb_reason_drop or kfree_skb() functions
• Kernel oops or panic messages referencing btintel_hw_error, __hci_cmd_sync_sk, or btintel_shutdown_combined
• Data race warnings from kernel sanitizers showing concurrent access to hdev->req_rsp or hdev->req_status
• Unexpected system crashes during Bluetooth device removal or shutdown operations on Intel adapters

Detection Strategies

• Enable KASAN (Kernel Address Sanitizer) and KCSAN (Kernel Concurrency Sanitizer) in kernel builds to detect memory safety violations and data races
• Monitor kernel logs (dmesg) for Bluetooth-related use-after-free or data race warnings
• Deploy endpoint detection solutions capable of monitoring kernel driver behavior and detecting anomalous memory access patterns
• Implement audit logging for Bluetooth device operations, particularly around device initialization and shutdown sequences

Monitoring Recommendations

• Configure SentinelOne agents to detect kernel exploitation attempts targeting Bluetooth subsystems
• Set up alerts for kernel panic events with stack traces containing btintel, hci_sync, or hci_core symbols
• Monitor for unusual patterns of Bluetooth hardware error events that could indicate exploitation attempts
• Implement centralized log aggregation to correlate Bluetooth-related kernel events across endpoints

How to Mitigate CVE-2026-31500

Immediate Actions Required

• Apply the latest kernel security patches from your Linux distribution that include the fix for CVE-2026-31500
• If immediate patching is not possible, consider temporarily disabling Intel Bluetooth adapters on critical systems
• Update kernel packages to versions containing commits 5f84e845648d, 66696648af47, 94d8e6fe5d08, e10a4cb72468, or f7d84737663a
• Deploy SentinelOne Singularity Platform for runtime protection against kernel exploitation attempts

Patch Information

The vulnerability has been addressed in multiple stable kernel branches. The fix implements proper serialization by wrapping the hardware error recovery sequence in hci_req_sync_lock/unlock calls within btintel_hw_error(). The patches are available in the following kernel commits:

• Kernel Patch 5f84e84
• Kernel Patch 66696648
• Kernel Patch 94d8e6fe
• Kernel Patch e10a4cb7
• Kernel Patch f7d84737

Workarounds

• Disable Intel Bluetooth adapters via kernel module blacklisting if they are not required for operations
• Use alternative Bluetooth adapters from other vendors that do not utilize the btintel driver
• Restrict physical access to systems where Bluetooth hardware errors could be triggered maliciously
• Enable kernel lockdown mode to limit kernel exploitation opportunities

# Temporarily disable Intel Bluetooth driver
sudo modprobe -r btintel
echo "blacklist btintel" | sudo tee /etc/modprobe.d/disable-btintel.conf

# Verify the module is not loaded
lsmod | grep btintel