CVE-2026-31771

What it actually does

This Linux kernel Bluetooth flaw occurs in HCI event processing. A malformed or abnormally short Bluetooth HCI event can reach wake-reason address handling before the kernel has validated the event-specific minimum payload length. The vulnerable path can cause an out-of-bounds memory access during Bluetooth address copying, with likely outcomes including kernel memory disclosure and kernel crash or panic. Because the attack vector is adjacent-network Bluetooth, exploitation generally requires the attacker to be within Bluetooth radio range or able to influence a Bluetooth controller/event stream. The CVSS score of 8.1 reflects high confidentiality and availability impact, with no privileges or user interaction required.

Why it matters to the business

Systems with enabled Bluetooth support may be exposed to nearby attackers who can trigger kernel instability or potentially expose sensitive kernel memory. Operationally, this can result in device crashes, service disruption, endpoint reboots, and degraded availability for laptops, workstations, embedded Linux devices, kiosks, industrial systems, or appliances that rely on Bluetooth. Although EPSS is currently low and there is no known KEV listing or public exploit maturity, the issue is kernel-level and remotely reachable over short range, so exposed Bluetooth-enabled fleets should still be prioritized for routine kernel updates and hardening.

How an attack unfolds

An attacker positions within Bluetooth range of a vulnerable Linux system or otherwise gains the ability to influence Bluetooth HCI event input. The attacker causes the Bluetooth stack to process a crafted, truncated HCI event associated with connection or advertising-related wake-reason handling. In vulnerable kernels, the event header is stripped and wake-reason storage is attempted before the per-event payload length checks run. The kernel then copies a Bluetooth address from data that has not been validated as present, causing an out-of-bounds access. Depending on memory layout, kernel configuration, and hardening features, this may disclose adjacent kernel memory, trigger a KASAN report, crash the Bluetooth subsystem, or panic the system.

How to fix it

Upgrade to a Linux kernel version or vendor-supported kernel package that includes the upstream Bluetooth HCI event validation fix moving wake-reason address storage into validated event handlers. No exact fixed package versions were provided in the input, so use the relevant distribution advisory, kernel stable release notes, or appliance vendor bulletin to identify the corrected build. Where immediate patching is not possible, reduce exposure by disabling Bluetooth, blocking Bluetooth adapters, unloading Bluetooth kernel modules where operationally safe, disabling Bluetooth in BIOS/UEFI or device policy, and limiting physical proximity exposure for high-value systems. Mitigations should be treated as temporary because the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel contains the vendor fix for the Bluetooth HCI event wake-reason validation issue. Validate both package installation and active runtime state: ensure the patched kernel package is installed, reboot into that kernel, and verify `uname -r` matches the corrected version. If Bluetooth is not required, verify it is disabled using system service status, rfkill state, loaded module checks, and endpoint configuration policy. For source-based validation, confirm wake-reason storage is performed only after per-event payload length validation in the affected HCI event handlers and that the helper asserts the HCI device lock is held. Review kernel logs after remediation to ensure no recurring Bluetooth HCI crashes, KASAN out-of-bounds findings, or panics occur during Bluetooth activity.

Typical attack path

1. Identify a Linux system with Bluetooth enabled and a vulnerable kernel build.
2. Move within Bluetooth radio range or gain control over an adjacent Bluetooth/HCI event source.
3. Send or induce a malformed short Bluetooth HCI event related to connection completion, connection requests, advertising reports, periodic advertising sync, or PAST-received handling.
4. Trigger the vulnerable wake-reason storage path before event-length validation has completed.
5. Cause an out-of-bounds kernel memory access, potentially resulting in kernel information exposure or denial of service.
6. Repeat the trigger to cause recurring crashes or operational disruption if the device remains unpatched and Bluetooth remains enabled.

How to detect it

Look for signs of prior exploitation or attempted triggering in kernel, system, Bluetooth, EDR, and crash telemetry. Relevant sources include `dmesg`, journald, `/var/log/kern.log`, `/var/log/messages`, `/var/crash`, `kdump` output, kernel panic records, KASAN reports, Bluetooth daemon logs, and endpoint reboot/crash timelines. Focus on Bluetooth-related kernel oopses, panics, slab or stack out-of-bounds reports, faults in HCI event processing, crashes near `hci_event_packet`, `hci_store_wake_reason`, or `bacpy`, and repeated failures correlated with Bluetooth activity or proximity events. Because exploitation occurs at the kernel/Bluetooth stack layer, network perimeter logs are unlikely to show useful evidence. Absence of logs does not prove absence of exploitation, especially if crash dumps are disabled or volatile logs were lost after reboot.

• hci_store_wake_reason
• hci_event_packet
• bacpy
• hci_conn_request_evt
• hci_conn_complete_evt
• hci_sync_conn_complete_evt
• le_conn_complete_evt
• hci_le_adv_report_evt
• hci_le_ext_adv_report_evt
• hci_le_direct_adv_report_evt
• hci_le_pa_sync_established_evt
• hci_le_past_received_evt
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: stack-out-of-bounds
• BUG: KASAN: global-out-of-bounds
• Bluetooth: hci
• kernel panic
• Oops:
• general protection fault
• /var/log/kern.log
• /var/log/messages
• /var/crash
• /proc/modules
• bluetooth
• btusb
• rfkill

What your security team should do

• Inventory Linux endpoints, servers, embedded devices, and appliances where Bluetooth hardware or kernel Bluetooth support is enabled.
• Prioritize patching Bluetooth-enabled systems, mobile workstations, kiosks, conference-room devices, industrial endpoints, and other systems physically accessible to untrusted nearby users.
• Apply vendor kernel updates that include the fixed Bluetooth HCI event handling logic, then reboot to activate the patched kernel.
• Disable Bluetooth on systems that do not require it, especially servers and high-value endpoints.
• Monitor kernel logs and crash telemetry for Bluetooth HCI event processing faults, KASAN out-of-bounds reports, kernel oopses, and unexpected reboots.
• For systems that cannot be patched promptly, document compensating controls such as Bluetooth disablement, physical access controls, and radio exposure reduction.
• Track distribution advisories for exact fixed kernel package versions because no fixed versions were provided in the vulnerability metadata.
• Treat evidence of repeated Bluetooth-triggered kernel crashes as suspicious even though there is currently no known exploitation in CISA KEV and EPSS remains low.