CVE-2026-63871 is a newly published Linux kernel Bluetooth fix for a data race in the ISO socket path, and the immediate task for administrators is to identify Linux systems running Bluetooth LE Audio workloads—not to treat it as a Windows Bluetooth vulnerability. The National Vulnerability Database published the record on July 19, 2026, with kernel.org as the source; it currently has no CVSS score, assigned CWE, or NVD severity assessment.
The flaw sits in
This is a correctness and stability defect confirmed by KCSAN, the Kernel Concurrency Sanitizer. It is not, at publication time, an advisory claiming remote code execution, privilege escalation, information disclosure, or active exploitation. That distinction matters: administrators should patch it through normal kernel maintenance, while avoiding severity claims the vulnerability record does not support.
The affected calls—
In ordinary terms, one execution path could be deciding which Bluetooth controller to use while another modifies the addressing information on which that decision depends. Concurrent reads and writes without the required synchronization are a data race: behavior can become inconsistent and, depending on timing and surrounding code, may produce unreliable or hard-to-reproduce outcomes.
The report’s KCSAN trace shows a read in
The fix is deliberately small. Kernel developers snapshot the route-selection fields while holding
Conversely, a custom kernel based directly on an affected stable tree needs a review of its patch set rather than an assumption that routine package updates have covered it. The CVE record references four stable commits, indicating the repair was carried across more than one maintained kernel branch.
For a quick first pass on a Linux endpoint, administrators can check the running kernel with:
That only establishes the baseline. The decisive question is whether the installed distribution kernel package includes the CVE-2026-63871 backport or the corresponding Bluetooth ISO patch. Package changelogs, vendor security trackers, and the distribution’s kernel source package are more authoritative than raw version comparison when backports are in play.
The Windows-relevant case is Windows Subsystem for Linux 2. Microsoft documents that WSL 2 runs a real Linux kernel inside its lightweight managed virtual machine, unlike WSL 1’s translation-based architecture. Microsoft also distributes the WSL kernel separately from the Windows operating-system image, so its update cadence and patch state must be assessed independently of the latest Windows cumulative update.
Microsoft’s WSL2-Linux-Kernel project had a 6.18.26.3 release in late May 2026, according to its public release listing. That upstream version number precedes Linux 6.18.36, one of the fixed releases identified in the CVE record. It would be premature, however, to declare a particular WSL release affected solely from that comparison: Microsoft can backport individual fixes, its kernel configuration may constrain the relevant Bluetooth ISO exposure, and users may have selected a custom WSL kernel.
The practical check for WSL 2 administrators is straightforward:
Then, inside a WSL 2 distribution:
There is also an exposure qualifier. A WSL 2 Linux kernel is not automatically equivalent to a conventional Linux laptop with a Bluetooth controller exposed to the guest and software using ISO sockets. Organizations should determine whether their WSL environment supports and uses the affected Bluetooth stack rather than escalating this CVE into a generic Windows fleet incident.
That does not mean every device with Bluetooth enabled has meaningful practical exposure. The affected code needs to be present, reachable, and used in a way that creates concurrent operations on the same ISO socket. Still, race conditions are especially unwelcome in audio and wireless stacks, where a rare timing fault can translate into intermittent connection problems that are expensive to diagnose after deployment.
For organizations operating kernel-managed Bluetooth on appliances or embedded products, the right response is to inventory builds that include
The next milestones are distribution advisories and backported package releases. Until those land, the most concrete action is to update WSL where it is deployed, verify custom WSL kernels separately, and ensure Linux systems using Bluetooth LE Audio move to a vendor kernel containing the
The flaw sits in
net/bluetooth/iso.c, the Linux kernel component for Bluetooth ISO, or Isochronous transport. ISO is the transport underpinning Bluetooth LE Audio use cases, including synchronized audio streams and broadcast audio. According to the kernel.org advisory mirrored in NVD, several ISO operations read socket routing fields without holding the socket lock, allowing those values to change concurrently through connect() or setsockopt().This is a correctness and stability defect confirmed by KCSAN, the Kernel Concurrency Sanitizer. It is not, at publication time, an advisory claiming remote code execution, privilege escalation, information disclosure, or active exploitation. That distinction matters: administrators should patch it through normal kernel maintenance, while avoiding severity claims the vulnerability record does not support.
The Race Is in Route Selection, Not the Bluetooth Radio Firmware
The affected calls—iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync()—invoke hci_get_route() using three fields associated with an ISO socket: destination address, source address, and source address type. The problem is that these fields could be read as part of device-route selection while another action on the same socket changed them.In ordinary terms, one execution path could be deciding which Bluetooth controller to use while another modifies the addressing information on which that decision depends. Concurrent reads and writes without the required synchronization are a data race: behavior can become inconsistent and, depending on timing and surrounding code, may produce unreliable or hard-to-reproduce outcomes.
The report’s KCSAN trace shows a read in
memcmp() reached from hci_get_route() and iso_connect_cis(), ultimately via the system connect() path. That is valuable evidence of the affected execution path, but it is not an exploit demonstration. KCSAN is designed to find concurrency hazards during testing, often before they surface as easily repeatable field failures.The fix is deliberately small. Kernel developers snapshot the route-selection fields while holding
lock_sock(), then pass those stable local values to hci_get_route() after the lock-protected read. That removes the unsafe window without holding a socket lock across the routing lookup itself.Fixed Kernels Are Already Identified, but Distribution Backports Still Decide the Real Answer
The NVD record identifies the vulnerability as present from Linux 6.2 onward, while also recording an older affected range beginning with Linux 6.1.9 and ending before 6.2. More importantly for operations teams, it names the stable-kernel fixed releases:- Linux 6.12.94 and later in the 6.12 stable series are listed as unaffected.
- Linux 6.18.36 and later in the 6.18 stable series are listed as unaffected.
- Linux 7.0.13 and later in the 7.0 stable series are listed as unaffected.
- Linux 7.1 includes the upstream fix.
Conversely, a custom kernel based directly on an affected stable tree needs a review of its patch set rather than an assumption that routine package updates have covered it. The CVE record references four stable commits, indicating the repair was carried across more than one maintained kernel branch.
For a quick first pass on a Linux endpoint, administrators can check the running kernel with:
uname -rThat only establishes the baseline. The decisive question is whether the installed distribution kernel package includes the CVE-2026-63871 backport or the corresponding Bluetooth ISO patch. Package changelogs, vendor security trackers, and the distribution’s kernel source package are more authoritative than raw version comparison when backports are in play.
Windows PCs Are Not Directly in Scope—WSL 2 Is the Edge Case Worth Checking
Windows 10 and Windows 11 do not use the Linuxnet/bluetooth/iso.c driver for their native Bluetooth stack. A Windows machine using Bluetooth headphones, LE Audio devices, or a Bluetooth adapter is therefore not made vulnerable to this specific kernel defect merely because Bluetooth is enabled.The Windows-relevant case is Windows Subsystem for Linux 2. Microsoft documents that WSL 2 runs a real Linux kernel inside its lightweight managed virtual machine, unlike WSL 1’s translation-based architecture. Microsoft also distributes the WSL kernel separately from the Windows operating-system image, so its update cadence and patch state must be assessed independently of the latest Windows cumulative update.
Microsoft’s WSL2-Linux-Kernel project had a 6.18.26.3 release in late May 2026, according to its public release listing. That upstream version number precedes Linux 6.18.36, one of the fixed releases identified in the CVE record. It would be premature, however, to declare a particular WSL release affected solely from that comparison: Microsoft can backport individual fixes, its kernel configuration may constrain the relevant Bluetooth ISO exposure, and users may have selected a custom WSL kernel.
The practical check for WSL 2 administrators is straightforward:
Code:
wsl --status
wsl --updateuname -rwsl --update is the appropriate first action for stock WSL installations because Microsoft states that the WSL kernel is updated independently. Environments using a custom kernel specified through .wslconfig need to update that custom image themselves; Microsoft’s WSL documentation explicitly supports custom kernel selection, so a successful Windows or Store-delivered WSL update may not change the kernel actually booted by that installation.There is also an exposure qualifier. A WSL 2 Linux kernel is not automatically equivalent to a conventional Linux laptop with a Bluetooth controller exposed to the guest and software using ISO sockets. Organizations should determine whether their WSL environment supports and uses the affected Bluetooth stack rather than escalating this CVE into a generic Windows fleet incident.
Bluetooth LE Audio and Embedded Linux Are the More Likely Operational Targets
The systems most likely to care immediately are Linux desktops, mobile and embedded products, test rigs, audio gateways, and devices actively implementing Bluetooth LE Audio through Linux’s Bluetooth stack. The advisory’s affected functions cover both connected and broadcast-oriented ISO workflows, including BIS and CIS operations and BIG synchronization. Those terms point to advanced LE Audio capabilities rather than ordinary classic-Bluetooth keyboard, mouse, or serial-device traffic.That does not mean every device with Bluetooth enabled has meaningful practical exposure. The affected code needs to be present, reachable, and used in a way that creates concurrent operations on the same ISO socket. Still, race conditions are especially unwelcome in audio and wireless stacks, where a rare timing fault can translate into intermittent connection problems that are expensive to diagnose after deployment.
For organizations operating kernel-managed Bluetooth on appliances or embedded products, the right response is to inventory builds that include
CONFIG_BT_ISO, determine whether the product exposes ISO sockets or LE Audio functionality, and schedule the vendor-supported kernel update. Disabling Bluetooth wholesale is not justified by the published record unless a local risk assessment finds a specific reason to do so.Treat This as a Patch-Verification Event, Not an Emergency Windows Bulletin
CVE-2026-63871 arrived in the NVD on July 19 with the repair already committed across stable Linux branches. Its publication provides a useful signal for patch and product teams, but the record does not currently establish a CVSS severity, a known exploitation path, or a direct impact on Windows’ native Bluetooth implementation.The next milestones are distribution advisories and backported package releases. Until those land, the most concrete action is to update WSL where it is deployed, verify custom WSL kernels separately, and ensure Linux systems using Bluetooth LE Audio move to a vendor kernel containing the
lock_sock() snapshot fix.References
- Primary source: NVD / Linux Kernel
Published: 2026-07-20T01:03:35-07:00
NVD - CVE-2026-63871
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-20T01:03:35-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
