CVE-2026-63871

What it actually does

This flaw is a race condition in the Linux kernel Bluetooth ISO socket handling code. Several Bluetooth ISO paths call hci_get_route() using socket fields such as destination address, source address, and source address type without holding the socket lock, while those same fields can be changed concurrently by connect() or setsockopt() on the same socket. The result is an unsynchronized read/write race in kernel memory, observed by KCSAN in memcmp() during route selection. The most plausible technical impact is local kernel instability, incorrect Bluetooth route selection, or a denial of service through a kernel warning, crash, or undefined behavior. There is no current evidence of public exploit maturity, known exploitation, KEV listing, or ransomware use.

Why it matters to the business

Systems that expose Linux Bluetooth functionality could be vulnerable to local misuse that affects host stability or Bluetooth-dependent operations. The business risk is highest for laptops, workstations, embedded Linux devices, IoT gateways, kiosks, industrial systems, and appliances where Bluetooth ISO functionality or untrusted local users are present. Because the issue is not currently known to be exploited and has a very low EPSS score, it is lower urgency than remotely exploitable kernel vulnerabilities, but it should still be remediated through normal kernel update cycles because kernel race conditions can cause outages and are difficult to monitor reliably.

How an attack unfolds

An attacker would first need the ability to execute code locally on a vulnerable Linux system and interact with Bluetooth sockets. They would create or manipulate an ISO Bluetooth socket, then repeatedly trigger connect() and/or setsockopt() operations from concurrent threads so that one execution path modifies ISO socket state while another path enters hci_get_route() and reads that same state without proper locking. By winning the race, the attacker may cause inconsistent kernel reads during Bluetooth route lookup, potentially leading to kernel warnings, crashes, or other undefined behavior. There is no indication from the provided data that this vulnerability has a weaponized public exploit or is being used by named threat actors.

How to fix it

Apply the Linux kernel update that includes the fix for this Bluetooth ISO locking issue. The fix snapshots the required ISO socket fields while holding lock_sock() before calling hci_get_route(), eliminating the unsynchronized access. Because no exact affected product list or fixed kernel versions were provided, track kernel advisories from the operating system or distribution vendor and upgrade to the first vendor kernel build that includes the CVE-2026-63871 fix. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, blocking untrusted local users from executing arbitrary code, limiting access to Bluetooth-related capabilities where practical, and prioritizing patching for multi-user systems or devices with active Bluetooth use.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package version is at or above the vendor-fixed version for this issue, not merely that an updated package is installed. Reboot into the patched kernel where required. Review vendor changelogs or kernel source backports for the Bluetooth ISO change that snapshots iso_pi socket fields under lock_sock() before hci_get_route(). On systems using source-based kernels, confirm that iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() no longer pass iso_pi(sk)->dst, iso_pi(sk)->src, or iso_pi(sk)->src_type directly to hci_get_route() without first taking the socket lock and copying the values. If Bluetooth is disabled as a mitigation, validate that Bluetooth kernel modules or services are not active and that local Bluetooth socket creation is not available to untrusted users.

Typical attack path

1. Obtain local code execution on a vulnerable Linux host where Bluetooth support is available.
2. Create or access a Bluetooth ISO socket using local system calls.
3. Run concurrent operations against the same socket, especially connect() and setsockopt(), to modify ISO socket fields while route lookup is occurring.
4. Trigger vulnerable Bluetooth ISO paths such as ISO CIS/BIS connection or listen/sync operations.
5. Cause an unsynchronized read/write race in hci_get_route(), potentially resulting in kernel instability, warnings, or denial of service.

How to detect it

Detection should focus on evidence of attempted local triggering and resulting kernel instability rather than network indicators. Review kernel logs from journald, syslog, dmesg, crash dumps, and EDR telemetry for KCSAN data-race reports or kernel call traces involving Bluetooth ISO functions and hci_get_route(). Look for repeated local processes making Bluetooth ISO socket connect() and setsockopt() calls in rapid succession, especially if followed by kernel warnings, oopses, lockdep/KCSAN messages, Bluetooth subsystem errors, or unexpected reboots. Useful log sources include /var/log/kern.log, /var/log/syslog, /var/log/messages, journalctl -k output, dmesg output, auditd syscall logs if enabled, eBPF syscall telemetry, EDR process telemetry, and kernel crash dump records. Because no public exploit, named threat actor, or ransomware use is indicated, any suspected activity should be investigated as opportunistic local abuse or testing unless correlated with broader intrusion evidence.

• BUG: KCSAN: data-race in memcmp
• hci_get_route+
• iso_connect_cis+
• iso_connect_bis+
• iso_listen_bis+
• iso_conn_big_sync+
• iso_sock_connect+
• __sys_connect_file+
• __x64_sys_connect+
• Bluetooth: ISO
• data-race in memcmp+
• race at unknown origin
• journalctl -k
• /var/log/kern.log
• /var/log/syslog
• /var/log/messages

What your security team should do

• Inventory Linux systems with Bluetooth enabled, especially endpoints, embedded systems, kiosks, and multi-user hosts.
• Patch affected systems through the normal kernel update process and reboot into the fixed kernel.
• Prioritize systems where untrusted users can run local code or where Bluetooth is operationally important.
• Disable Bluetooth on servers and appliances that do not require it.
• Monitor kernel logs for KCSAN reports, Bluetooth ISO stack traces, kernel oopses, panics, or repeated local Bluetooth socket errors.
• Treat signs of exploitation as local post-compromise activity and investigate the user account, process tree, and binaries responsible for Bluetooth socket activity.
• Track distribution advisories for exact fixed kernel package versions because fixed versions were not supplied in the input.