CVE-2026-64403

What it actually does

This is a Linux kernel Bluetooth L2CAP parsing flaw in configuration option handling. A nearby, unauthenticated attacker can send a malformed L2CAP configuration request or response with an attacker-controlled option length that causes the kernel to read up to 4 bytes beyond the end of the received buffer before validating that the bytes are present. The current control flow is described as preventing the out-of-bounds value from being used as a meaningful data leak, but the validate-after-use behavior can still trigger memory-safety faults, kernel warnings, KASAN reports, or a kernel crash depending on build options, memory layout, and runtime conditions. The practical impact is primarily local-adjacent denial of service against systems with Bluetooth enabled, with limited confidentiality exposure from the out-of-bounds read.

Why it matters to the business

Systems with Bluetooth enabled may be vulnerable to disruption from an attacker in radio range, potentially causing device instability, service interruption, or kernel crashes without requiring credentials or user interaction. The risk is most relevant for laptops, workstations, embedded Linux devices, kiosks, medical/industrial endpoints, and IoT products that expose Bluetooth in public or semi-public spaces. The issue is not currently listed in CISA KEV, is not reported as ransomware-used, and has low EPSS at the time of assessment, so broad internet-scale exploitation is unlikely; however, the adjacent-network attack model makes it important for fleets where physical proximity attacks are credible.

How an attack unfolds

An attacker must be within Bluetooth range of a vulnerable Linux system with Bluetooth enabled and reachable. The attacker initiates or manipulates an L2CAP connection and sends a crafted configuration request or response containing a malformed configuration option whose length field claims bytes that are not actually present in the packet buffer. Vulnerable kernel code reads the option value before confirming the full option fits inside the received buffer. Because the parser later rejects the malformed option, the attacker is not expected to directly receive kernel memory contents in the known vulnerable path. The more realistic exploitation outcome is inducing an out-of-bounds read that may be detected by kernel hardening instrumentation or may destabilize the Bluetooth stack or kernel, resulting in denial of service.

How to fix it

Apply a Linux kernel update that includes the Bluetooth L2CAP fix which validates the full configuration option length before reading option values. If distribution-specific fixed versions are not available, track vendor advisories for the affected kernel packages and update to the first kernel build that includes the upstream fix for L2CAP option-length validation. As interim mitigations, disable Bluetooth where it is not required, block automatic Bluetooth pairing/discovery, remove or blacklist Bluetooth kernel modules where operationally acceptable, and restrict Bluetooth exposure on systems in public or high-risk physical environments. Embedded and appliance vendors should backport the fix into maintained kernel branches and test Bluetooth L2CAP interoperability after patching.

How to confirm the fix worked

Confirm the running kernel version is a vendor build that contains the L2CAP option-length validation fix; do not rely only on package installation status because systems must boot into the updated kernel. Verify Bluetooth exposure by checking whether Bluetooth services are enabled and whether relevant kernel modules are loaded. Where safe and authorized, use a Bluetooth protocol test harness or vendor regression test to send malformed L2CAP configuration options and confirm the system rejects them without kernel warnings, KASAN reports, Bluetooth stack resets, or crashes. Review distribution advisories, kernel changelogs, and backport notes for references to validating L2CAP configuration option lengths before reading option values.

Typical attack path

1. Identify a Linux target with Bluetooth enabled and within radio range.
2. Establish Bluetooth/L2CAP interaction with the target or reach the L2CAP configuration parsing path during channel setup.
3. Send a malformed L2CAP configuration request or response with an option length that exceeds the remaining packet buffer.
4. Trigger the vulnerable parser to read the option value before validating that the full option is present.
5. Cause kernel memory-safety handling, Bluetooth stack instability, or a kernel crash depending on configuration and runtime behavior.

How to detect it

Retrospective detection should focus on signs of malformed Bluetooth L2CAP traffic followed by kernel memory-safety errors, Bluetooth subsystem faults, or unexpected reboots. Useful log sources include kernel logs, system journal entries, crash dumps, pstore/ramoops records, KASAN or UBSAN output, Bluetooth daemon logs, endpoint telemetry for kernel panics, and uptime/reboot records. Look for temporal correlation between Bluetooth activity and messages referencing L2CAP configuration parsing functions, out-of-bounds reads, kernel oopses, general protection faults, or Bluetooth controller resets. Network SIEM visibility is often limited because exploitation occurs over Bluetooth radio rather than IP; organizations with Bluetooth monitoring, HCI snoop logs, or btmon captures should search for malformed L2CAP configuration request/response packets with option lengths that exceed the remaining payload. Absence of logs does not prove absence of exploitation because a crash may truncate evidence and many systems do not retain detailed Bluetooth packet telemetry by default.

• l2cap_get_conf_opt
• l2cap_parse_conf_req
• l2cap_parse_conf_rsp
• l2cap_conf_rfc_get
• Bluetooth: L2CAP
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• KASAN: invalid-access
• kernel BUG at net/bluetooth/l2cap_core.c
• Oops: general protection fault
• Bluetooth: hci
• btmon
• L2CAP Config Request
• L2CAP Config Response

What your security team should do

• Inventory Linux systems with Bluetooth enabled, prioritizing laptops, mobile workstations, kiosks, embedded devices, and assets in public or shared physical spaces.
• Patch affected Linux kernels as vendor updates become available and verify systems have rebooted into the fixed kernel.
• Disable Bluetooth on servers and endpoints that do not require it.
• For high-risk locations, reduce Bluetooth discoverability and pairing exposure until fixed kernels are deployed.
• Monitor kernel logs for Bluetooth L2CAP parsing errors, kernel oopses, KASAN out-of-bounds reports, and unexpected reboots.
• Add this issue to embedded Linux and appliance firmware maintenance backlogs, especially where kernel updates lag distribution releases.