CVE-2026-31772

What it actually does

This is a local Linux kernel stack buffer overflow in the Bluetooth ISO/BIG synchronization path. The vulnerable function allocates stack space for 17 Broadcast Isochronous Stream entries but accepts up to 31 entries from a validated connection structure; when more than 17 entries are provided, a memcpy writes beyond the stack buffer and corrupts adjacent kernel stack memory. Because the overwrite occurs in kernel context, successful exploitation can plausibly cause kernel crashes and may allow local privilege escalation or arbitrary kernel memory corruption, depending on architecture, compiler hardening, kernel configuration, and stack layout.

Why it matters to the business

A user or process with local access to an affected Linux system could potentially crash the system or escalate privileges to take control of the host. Systems exposing Bluetooth functionality, especially desktops, laptops, embedded Linux devices, IoT gateways, and servers with Bluetooth hardware or enabled Bluetooth kernel modules, are the most relevant. The current public exploitation signal is low: EPSS is 0.00142 and flat over 30 days, it is not listed in CISA KEV, and no mature public exploit is indicated; however, kernel memory corruption flaws still warrant timely remediation because they can be chained with initial access to gain full system control.

How an attack unfolds

An attacker first needs local code execution or an account capable of interacting with the affected Bluetooth/ISO socket functionality. They create or trigger a Bluetooth ISO/BIG synchronization flow with a number of BIS entries greater than the stack allocation size but within the caller-accepted maximum. The vulnerable kernel worker later processes that state in hci_le_big_create_sync(), copies too many bytes into the undersized stack buffer, and corrupts nearby kernel stack memory. In the simplest case this results in a kernel warning, KASAN report, oops, panic, Bluetooth subsystem failure, or denial of service. With additional exploit development, an attacker may attempt to shape the overwritten stack data to alter control flow or kernel data and escalate privileges.

How to fix it

Apply a Linux kernel update from the relevant distribution, device vendor, or upstream-stable kernel branch that includes the fix changing the hci_le_big_create_sync() flexible array allocation to HCI_MAX_ISO_BIS. No exact fixed package versions were provided in the input, so track vendor advisories for kernel packages matching the affected Linux kernel build. If immediate patching is not possible, reduce exposure by disabling Bluetooth where it is not required, removing or blacklisting Bluetooth-related kernel modules such as bluetooth and btusb where operationally acceptable, disabling Bluetooth services, and limiting local user access on systems where Bluetooth remains enabled. Treat these mitigations as temporary; the durable fix is a patched kernel followed by a reboot into the corrected kernel.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated to a build containing the upstream Bluetooth hci_sync fix for hci_le_big_create_sync(). Validate with vendor advisory metadata, changelogs, kernel package version, and reboot status. Confirm Bluetooth modules are disabled or unloaded where mitigation is used. Review dmesg or journal output after patching for absence of KASAN, stack-out-of-bounds, kernel oops, panic, or Bluetooth HCI sync worker crashes involving hci_le_big_create_sync. In test environments with appropriate authorization and safety controls, a non-production validation can confirm that attempts to exercise high BIS-count ISO socket behavior no longer produce stack-out-of-bounds reports or kernel instability.

Typical attack path

1. Obtain local code execution, an interactive account, or the ability to run a local process on an affected Linux host.
2. Confirm Bluetooth and ISO socket functionality are available through the running kernel and loaded Bluetooth modules.
3. Create or bind a Bluetooth ISO socket using a BIS count above 17 and up to the accepted maximum of 31.
4. Trigger the listen/synchronization path that causes the HCI command sync worker to call hci_le_big_create_sync().
5. Cause the kernel memcpy to write past the stack-allocated buffer.
6. Leverage the resulting kernel memory corruption for denial of service, or attempt further exploitation for local privilege escalation.

How to detect it

To determine whether exploitation or attempted exploitation has already occurred, review kernel and system logs such as dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, and kernel panic/oops records for Bluetooth ISO/BIG activity followed by stack buffer overflow, KASAN, oops, or panic messages. Look specifically for references to hci_le_big_create_sync, hci_conn_big_create_sync, HCI command sync workers, ISO sockets, BIS counts near 31, and stack-out-of-bounds writes. On systems with crash dump collection enabled, inspect vmcore/kdump artifacts for crashes in the Bluetooth HCI sync worker path. Also review audit or endpoint telemetry for unusual local processes opening Bluetooth ISO sockets, loading Bluetooth modules unexpectedly, or repeatedly triggering kernel faults. There are no known network indicators from the provided information because exploitation is local and occurs through kernel Bluetooth socket handling rather than a distinctive remote packet signature.

• BUG: KASAN: stack-out-of-bounds in hci_le_big_create_sync
• hci_le_big_create_sync+0x
• Write of size 31
• by task kworker/u9:0
• hci_conn_big_create_sync
• hci_le_big_create_sync
• stack-out-of-bounds
• KASAN: stack-out-of-bounds
• Bluetooth: hci_sync
• HCI command sync
• ISO_MAX_NUM_BIS
• HCI_MAX_ISO_BIS
• bc_num_bis = ISO_MAX_NUM_BIS
• kernel: BUG: KASAN: stack-out-of-bounds
• kernel: Bluetooth
• kernel: hci_le_big_create_sync
• kernel panic
• Oops:
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /proc/vmcore

What your security team should do

• Prioritize patching affected Linux kernels on systems with Bluetooth hardware, enabled Bluetooth services, untrusted local users, multi-user workloads, kiosk/desktop use cases, or container workloads that may permit access to Bluetooth sockets.
• Inventory Linux assets where Bluetooth kernel modules are loaded or Bluetooth services are enabled, including embedded and appliance-like systems that may not be part of standard server patch cycles.
• Where patching is delayed, disable Bluetooth functionality and blacklist unnecessary Bluetooth modules, then verify the modules do not reload after reboot.
• Restrict local shell access and reduce the ability of untrusted users or containers to access Bluetooth sockets or device interfaces.
• Monitor kernel logs for KASAN stack-out-of-bounds reports, kernel oopses, panics, and Bluetooth HCI worker failures referencing hci_le_big_create_sync, hci_conn_big_create_sync, ISO sockets, or BIS counts.
• Because public exploitation indicators are currently low and the issue is not in KEV, handle as a high-impact local privilege-escalation risk rather than an internet-facing emergency, unless Bluetooth is broadly enabled on exposed multi-user systems.