CVE-2026-31500

What it actually does

This is a local Linux kernel use-after-free in the Intel Bluetooth driver path. The btintel_hw_error() recovery routine issues synchronous HCI commands without holding hci_req_sync_lock(), allowing it to race with device close/shutdown logic in hci_dev_do_close() and btintel_shutdown_combined(). If both paths concurrently manipulate the Bluetooth device request response state, one path can free an skb response buffer while the other still references it, causing slab use-after-free memory access in kernel context. Successful exploitation could corrupt kernel memory and may enable local privilege escalation, kernel crash, or denial of service on systems using affected Intel Bluetooth hardware and vulnerable kernels.

Why it matters to the business

An attacker who already has local code execution on an affected Linux system may be able to crash the host or potentially gain elevated privileges. The operational risk is highest for workstations, laptops, kiosks, and edge devices with Intel Bluetooth enabled, because exploitation could turn a low-privileged local foothold into full system compromise. EPSS is currently very low and no known exploited-in-the-wild or ransomware use is reported, so this should be prioritized as part of kernel patch management rather than treated as an active mass-exploitation emergency.

How an attack unfolds

An attacker first needs the ability to execute code locally as a non-privileged user on a vulnerable Linux system with the affected Bluetooth stack and Intel Bluetooth driver in use. The attacker then attempts to trigger the Bluetooth Intel hardware error recovery path while simultaneously causing Bluetooth device close or shutdown operations, creating a race between btintel_hw_error() and hci_dev_do_close()/btintel_shutdown_combined(). Because the vulnerable recovery path does not serialize synchronous HCI commands with hci_req_sync_lock(), the two paths can operate on shared hdev request response state at the same time. In the losing interleaving, the shutdown path frees an skb response object while the hardware error path continues to access it, producing a kernel slab use-after-free. Depending on kernel configuration, timing, allocator behavior, and exploit reliability, this may result in a kernel panic or could be shaped into kernel memory corruption for local privilege escalation.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the Intel Bluetooth btintel_hw_error() locking issue. The fix serializes the full btintel_hw_error() recovery sequence with hci_req_sync_lock()/hci_req_sync_unlock(), preventing concurrent synchronous HCI command users from racing over hdev request response state. No exact fixed package versions were provided in the input, so use distribution vendor advisories for the specific kernel package in use and apply the latest supported stable or long-term-support kernel update. If immediate patching is not possible, reduce exposure by disabling Bluetooth where it is not operationally required, blocking untrusted local shell access, restricting users from controlling Bluetooth services/devices where feasible, and monitoring for kernel crashes or KASAN/use-after-free reports involving btintel or HCI sync code.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is at or above the vendor-fixed version for this issue, not merely that an updated package is installed on disk. Reboot into the patched kernel and verify with uname -a and the distribution package manager. Where source or build metadata is available, confirm the btintel_hw_error() path is wrapped with hci_req_sync_lock()/hci_req_sync_unlock(). Validate exposure by checking whether Intel Bluetooth hardware/driver support is present and active using tools such as lsmod, dmesg, bluetoothctl, hciconfig, btmgmt, lspci, and lsusb. Review kernel logs after patching to ensure no recurring KASAN, slab-use-after-free, Bluetooth HCI reset, or btintel shutdown race messages are observed.

Typical attack path

1. Gain local code execution on a vulnerable Linux host, for example as an unprivileged user.
2. Confirm that Bluetooth is present, enabled, and using the affected Intel Bluetooth driver path.
3. Repeatedly trigger Bluetooth hardware error recovery behavior while concurrently closing, resetting, disabling, or otherwise causing shutdown of the Bluetooth HCI device.
4. Win the race between btintel_hw_error() and hci_dev_do_close()/btintel_shutdown_combined() so shared HCI request response state is accessed after being freed.
5. Leverage the resulting kernel use-after-free to crash the system or attempt controlled kernel memory corruption for privilege escalation.

How to detect it

Look for evidence of attempted exploitation or crash-triggering in kernel and system logs. Primary sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore data, apport/ABRT reports, and EDR kernel panic telemetry. Search for KASAN or slab use-after-free reports involving btintel_hw_error(), btintel_shutdown_combined(), __hci_cmd_sync_sk(), hci_dev_do_close(), hci_error_reset(), kfree_skb(), or sk_skb_reason_drop(). Also review Bluetooth service logs for repeated HCI resets, adapter disable/enable loops, unexpected Bluetooth device close events, or frequent local invocations of bluetoothctl, btmgmt, hciconfig, rfkill, or service restarts immediately before a kernel crash. Since this issue is a race condition and no public exploit indicators are known, absence of logs does not prove non-exploitation; prioritize crash correlation, suspicious local user activity around Bluetooth control, and recurring kernel memory corruption signatures.

• BUG: KASAN: slab-use-after-free
• slab-use-after-free in sk_skb_reason_drop
• sk_skb_reason_drop+0x43/0x380 net/core/skbuff.c:1202
• BUG: data-race in __hci_cmd_sync_sk / btintel_shutdown_combined
• __hci_cmd_sync_sk
• __hci_cmd_sync
• btintel_hw_error
• btintel_shutdown_combined
• hci_error_reset
• hci_dev_close_sync
• hci_dev_do_close
• kfree_skb
• drivers/bluetooth/btintel.c
• net/bluetooth/hci_sync.c
• net/bluetooth/hci_core.c
• Bluetooth: btintel
• HCI_OP_RESET
• Intel exception-info
• hdev->req_rsp
• hdev->req_status

What your security team should do

• Inventory Linux laptops, workstations, edge systems, and servers with Bluetooth enabled, prioritizing systems using Intel Bluetooth hardware or btintel-related drivers.
• Apply vendor kernel updates that include the btintel_hw_error() hci_req_sync_lock serialization fix, and ensure systems are rebooted into the patched kernel.
• Disable Bluetooth on systems where it is not required, especially shared workstations, kiosks, production servers, and high-trust administrative endpoints.
• Treat exploitation as a local privilege-escalation risk: prioritize patching on systems where untrusted users, containers, remote desktop users, or exposed local accounts can run code.
• Monitor kernel logs and crash telemetry for KASAN, slab-use-after-free, btintel_hw_error(), btintel_shutdown_combined(), and __hci_cmd_sync_sk indicators.
• Because the vulnerability is not currently in CISA KEV and has very low EPSS with no reported mature exploit, track it through standard kernel vulnerability management while escalating if exploit code or in-the-wild activity emerges.