CVE-2026-31512

What it actually does

This is a Linux kernel Bluetooth L2CAP bounds-checking flaw in the Enhanced Credit Based Flow Control receive path. The vulnerable function reads a 2-byte SDU length field from packet data before confirming that the received socket buffer actually contains 2 bytes. A malformed or truncated L2CAP packet can therefore trigger an out-of-bounds read in kernel context. The expected impact is denial of service, such as a kernel warning, fault, panic, or Bluetooth stack instability; the provided scoring and description do not indicate confidentiality or integrity impact.

Why it matters to the business

Systems with Bluetooth enabled may be susceptible to local denial-of-service conditions that can interrupt endpoint, embedded, kiosk, mobile, workstation, or appliance operations. Because this affects the Linux kernel, exposure can extend broadly across distributions and downstream products, but exploitation currently appears low-likelihood: EPSS is very low and flat over 30 days, it is not listed in CISA KEV, and no public exploit maturity is reported. Organizations that rely on Bluetooth-enabled Linux devices in operational settings should still prioritize vendor kernel updates or disable Bluetooth where it is unnecessary.

How an attack unfolds

An attacker first needs a path to exercise the Linux Bluetooth L2CAP Enhanced Credit Based Flow Control data path, typically from a local low-privileged context capable of interacting with Bluetooth functionality or otherwise causing crafted L2CAP traffic to reach the vulnerable code. The attacker then sends or injects a malformed L2CAP data unit whose buffer length is shorter than the 2-byte SDU length field expected by l2cap_ecred_data_rcv(). Because the vulnerable kernel code reads the SDU length before validating the buffer length, the read occurs beyond the valid packet data. Depending on kernel configuration, memory layout, and hardening features, this can produce a kernel fault, KASAN report, panic, or Bluetooth subsystem crash, resulting in denial of service.

How to fix it

Upgrade affected Linux kernels to a vendor-supported build that includes the Bluetooth L2CAP fix adding a length validation before reading the SDU length in l2cap_ecred_data_rcv(). Because no exact fixed package versions were provided, use the relevant Linux distribution, appliance, or device vendor advisory to identify the corrected kernel release. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, blocking automatic loading of Bluetooth kernel modules, disabling Bluetooth services, and restricting local access to systems where untrusted users could exercise Bluetooth functionality. For high-availability systems, test kernel updates before broad rollout and schedule maintenance windows because remediation generally requires a reboot into the patched kernel.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version matches a vendor release containing the L2CAP ECRED bounds-check patch, not merely that the package is installed. Validate after reboot with standard kernel inventory commands and package manager metadata for the relevant distribution. Confirm whether Bluetooth is enabled by checking loaded modules, Bluetooth services, and adapter state. If source validation is available, confirm that l2cap_ecred_data_rcv() performs a length check equivalent to ensuring at least L2CAP_SDULEN_SIZE bytes are present before calling get_unaligned_le16() on skb data. Exposure is reduced if Bluetooth modules are not loaded, Bluetooth services are disabled, or no Bluetooth adapter is available; however, the durable fix is a patched kernel.

Typical attack path

1. Identify a Linux system with Bluetooth support enabled and a kernel containing the vulnerable L2CAP ECRED receive path.
2. Obtain local low-privileged access or another permitted route to interact with Bluetooth L2CAP functionality.
3. Create or reach an L2CAP Enhanced Credit Based Flow Control channel.
4. Send a malformed or truncated L2CAP payload shorter than the required 2-byte SDU length field.
5. Trigger the vulnerable l2cap_ecred_data_rcv() code path, causing an out-of-bounds kernel read.
6. Cause Bluetooth stack instability or a broader kernel denial-of-service condition such as an oops or panic.

How to detect it

Retrospective detection should focus on evidence of attempted denial of service rather than traditional persistence artifacts. Review kernel logs, system journals, crash dumps, kdump/vmcore records, pstore, and endpoint telemetry for kernel oopses, panics, KASAN reports, or call traces involving the Bluetooth L2CAP receive path, especially l2cap_ecred_data_rcv(). Correlate these events with unexpected reboots, Bluetooth service failures, adapter resets, or local user activity involving Bluetooth sockets. On systems with audit or eBPF telemetry, look for unusual low-privileged processes creating AF_BLUETOOTH or L2CAP sockets shortly before a crash. Bluetooth daemon logs may show connection/channel setup anomalies, but the vulnerable code is in the kernel, so kernel logs are the primary evidence source. There are no known named threat actors, ransomware use, KEV listing, or public exploit maturity in the supplied data, so absence of these artifacts does not prove safety; it only lowers current exploitation likelihood.

• l2cap_ecred_data_rcv
• get_unaligned_le16
• L2CAP_SDULEN_SIZE
• Bluetooth: L2CAP
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: KASAN
• kernel BUG
• Oops:
• Kernel panic
• Call Trace:
• Bluetooth:
• L2CAP
• AF_BLUETOOTH
• BTPROTO_L2CAP
• btusb
• bluetoothd

What your security team should do

• Inventory Linux systems with Bluetooth hardware, Bluetooth kernel modules loaded, or Bluetooth services enabled.
• Prioritize patching Bluetooth-enabled Linux endpoints, embedded systems, and operational devices where a crash would cause business disruption.
• Track distribution and vendor advisories for the corrected kernel version, then reboot systems into the patched kernel.
• Disable Bluetooth on servers, appliances, and workstations that do not require it.
• For systems where Bluetooth must remain enabled, restrict local interactive access and monitor for kernel crashes or Bluetooth L2CAP anomalies.
• Add SOC searches for kernel oops, panic, KASAN, or call traces referencing l2cap_ecred_data_rcv, L2CAP, or Bluetooth shortly before unexpected reboots.
• Because EPSS is low, flat, and there is no KEV listing, treat this as patch-management priority rather than emergency internet-wide exploitation response unless local threat conditions differ.