CVE-2026-31497

What it actually does

This is a local Linux kernel memory-safety flaw in the Bluetooth USB driver. In btusb_work(), the driver maps the number of active SCO voice links to a small alternate-setting lookup table, but it can index that table using data->sco_num - 1 without first limiting sco_num to the three entries actually present. If the active SCO link count exceeds the supported table size, the driver can read past the end of the alts[] array. The most likely security impact is a kernel fault or driver instability causing denial of service; confidentiality and integrity impact are not indicated by the published CVSS vector.

Why it matters to the business

Systems using affected Linux kernels with Bluetooth USB support may be susceptible to local denial-of-service conditions, potentially causing crashes or loss of Bluetooth functionality. The risk is lower than remotely exploitable kernel issues because exploitation requires local access and a Bluetooth/SCO-related execution path, EPSS is very low, there is no CISA KEV listing, and no public exploit maturity is reported. Organizations with laptops, workstations, kiosks, embedded Linux devices, or appliances that keep Bluetooth enabled should still patch through normal kernel maintenance because kernel crashes can disrupt user productivity and device availability.

How an attack unfolds

An attacker with local access to an affected Linux system first needs to reach the Bluetooth stack and trigger conditions where the btusb driver processes SCO voice-link state, such as Bluetooth audio or telephony-style traffic using CVSD transparent voice settings. The attacker then causes the host controller state to report more active SCO links than the driver’s three-entry alternate-setting table supports. When btusb_work() runs, the vulnerable code uses the unconstrained SCO count as an index into alts[]. A value above the expected range causes an out-of-bounds read. Depending on adjacent memory and driver behavior, this can select an invalid USB alternate setting or trigger a kernel fault, resulting in Bluetooth malfunction or a broader system denial of service.

How to fix it

Apply a Linux kernel update that includes the btusb fix to clamp SCO alternate-setting table indices before indexing alts[]. Because no exact fixed package versions were provided, use the latest security kernel available from the relevant Linux distribution or kernel vendor and reboot into the updated kernel. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, blocking untrusted local users from Bluetooth management capabilities, and removing or blacklisting the btusb module where operationally acceptable. Example mitigations include disabling the Bluetooth service, disabling Bluetooth in firmware/BIOS where available, or preventing btusb from loading; validate these changes against business and device-management requirements before broad deployment.

How to confirm the fix worked

Confirm systems are no longer running an affected kernel by checking the active kernel version after reboot and comparing it with the distribution’s advisory or patched kernel build. Verify that the btusb driver either comes from a patched kernel or is disabled where mitigation was chosen. On representative systems, confirm Bluetooth behavior remains stable during normal audio/headset use and that kernel logs do not show btusb, Bluetooth, USB alternate-setting, or kernel oops messages. For source-based validation, confirm the btusb SCO alternate-setting selection clamps the SCO count to the maximum valid alts[] index before array access.

Typical attack path

1. Obtain local code execution or an account on an affected Linux system.
2. Confirm Bluetooth is enabled and the btusb kernel driver is in use with compatible USB Bluetooth hardware.
3. Interact with the Bluetooth stack to establish or manipulate SCO voice-link activity.
4. Drive the active SCO link count beyond the number of alternate settings expected by the btusb lookup table.
5. Trigger btusb_work() so it indexes the alternate-setting table using the excessive SCO count.
6. Cause an out-of-bounds read that may crash the kernel, destabilize the btusb driver, or disrupt Bluetooth functionality.

How to detect it

Detection should focus on evidence of prior kernel instability around Bluetooth SCO activity and the btusb driver. Review system journal, kernel ring buffer, persistent kernel logs, crash dumps, and endpoint telemetry for btusb errors, Bluetooth SCO events preceding crashes, kernel oops traces referencing btusb_work, hci_conn_num, SCO, USB alternate settings, or array/index faults. Correlate these events with local user sessions, recently run Bluetooth utilities, unexpected Bluetooth audio/headset pairing attempts, and system reboots or panic events. Because the advisory does not identify a public exploit, malware family, network payload, or actor-specific tradecraft, absence of these artifacts does not prove non-exploitation; prioritize finding suspicious local activity followed by Bluetooth driver faults or denial-of-service symptoms.

• btusb_work
• btusb
• Bluetooth: btusb
• SCO
• CVSD
• transparent voice
• hci_conn_num
• kernel oops
• BUG: kernel NULL pointer dereference
• general protection fault
• Kernel panic
• Oops:
• usb_set_interface
• Bluetooth: hci
• /var/log/kern.log
• /var/log/messages
• /var/crash/
• /sys/module/btusb
• btusb.ko

What your security team should do

• Prioritize patching Linux laptops, workstations, kiosks, and embedded devices that have Bluetooth enabled and use USB Bluetooth adapters or integrated USB-attached Bluetooth controllers.
• Deploy vendor-supported kernel updates during the next normal patch cycle; accelerate for systems where local users are untrusted or service availability is critical.
• Reboot systems after kernel updates and verify they are running the patched kernel, not only that the package is installed.
• Disable Bluetooth or blacklist the btusb module on systems that do not require Bluetooth functionality.
• Review kernel logs and endpoint telemetry for recent Bluetooth-related kernel oops, BUG, panic, or btusb errors that may indicate attempted triggering or unstable exposure.
• Track distribution advisories for exact fixed package versions because upstream kernel fixes are often backported without changing to an obvious upstream version number.