CVE-2026-64127: Linux Kernel Bluetooth L2CAP Vulnerability

CVE-2026-64127 Overview

CVE-2026-64127 is a Linux kernel information disclosure vulnerability in the Bluetooth L2CAP subsystem. The flaw resides in the l2cap_ecred_reconfigure() function, which incorrectly transmits 8 bytes of kernel stack memory to a paired Bluetooth peer instead of the intended 6-byte reconfiguration payload. The leaked bytes contain a kernel virtual address subject to KASLR randomization, enabling an attacker with a paired Bluetooth connection to defeat kernel address space layout randomization. The bug was introduced by commit 1c08108f3014 when the on-stack packed struct was converted to DEFINE_RAW_FLEX() without updating the size and pointer arguments passed to l2cap_send_cmd().

Critical Impact
A paired Bluetooth peer can receive a kernel stack address on every L2CAP Enhanced Credit Based Flow Control reconfiguration request, weakening KASLR and breaking the L2CAP_ECRED_RECONFIGURE feature for local-side initiators.

Affected Products

Linux kernel versions containing commit 1c08108f3014 ("Bluetooth: L2CAP: Avoid -Wflex-array-member-not-at-end warnings")
Validated on a stock 7.0-based host kernel per the upstream commit message
Distributions shipping the affected kernel with Bluetooth L2CAP EXT_FLOWCTL support enabled

Discovery Timeline

2026-07-19 - CVE-2026-64127 published to NVD
2026-07-19 - Last updated in NVD database

Technical Details for CVE-2026-64127

Vulnerability Analysis

The vulnerability is a kernel memory information disclosure [CWE-200] in the L2CAP Enhanced Credit Based Flow Control reconfiguration path. When user space triggers a reconfiguration via setsockopt(SOL_BLUETOOTH, BT_RCVMTU, ...) on a BT_CONNECTEDL2CAP_MODE_EXT_FLOWCTL socket, the kernel builds an L2CAP_ECRED_RECONF_REQ PDU on the stack and sends it to the paired peer.

After the refactor, DEFINE_RAW_FLEX() expands to declare an anonymous union plus a local pointer named pdu that references it. The subsequent call l2cap_send_cmd(conn, chan->ident, L2CAP_ECRED_RECONF_REQ, sizeof(pdu), &pdu) now evaluates sizeof(pdu) as the size of a pointer (8 bytes on 64-bit systems) and passes the address of the local pointer variable rather than the payload. l2cap_send_cmd() forwards these arguments to l2cap_build_cmd(), which calls skb_put_data() and copies 8 bytes of raw kernel stack memory into the outbound frame.

Root Cause

The root cause is an incomplete API conversion. The sibling function l2cap_ecred_conn_req() was converted correctly using sizeof(*pdu) + len and passing pdu directly, but l2cap_ecred_reconfigure() retained the original sizeof(pdu), &pdu semantics. Because pdu is now a pointer rather than an inline struct, both operands changed meaning, producing a size/source mismatch that reads adjacent stack storage.

Attack Vector

Exploitation requires an established Bluetooth pairing and a connected L2CAP channel operating in Enhanced Credit Based Flow Control mode. When the local initiator issues a reconfiguration request, the peer receives an 8-byte body containing the on-stack pointer value. Captures from the upstream commit message demonstrate the leak, with the high 0xffff bytes confirming a KASLR-randomized kernel virtual address:

RECONF_REQ body (ident=0x02 len=8): 42 fb 54 af 0e ca ff ff
RECONF_REQ body (ident=0x02 len=8): 52 3d 2e af 0e ca ff ff
RECONF_REQ body (ident=0x02 len=8): b2 fc 5b af 0e ca ff ff

A malicious paired device can harvest these addresses to derandomize the kernel stack and chain the leak with a separate memory corruption primitive.

Detection Methods for CVE-2026-64127

Indicators of Compromise

Outbound L2CAP_ECRED_RECONFIGURE_REQ PDUs with a body length of 8 bytes rather than the expected 6 bytes
Reconfiguration requests rejected by the peer as malformed because the mtu, mps, and scid fields are absent
Unexpected reconfiguration attempts from L2CAP_MODE_EXT_FLOWCTL sockets on paired Bluetooth links

Detection Strategies

Inspect HCI snoop logs (btmon, hcidump) for L2CAP_ECRED_RECONF_REQ frames whose payload length equals 8 and whose upper bytes match 0xffff on 64-bit hosts
Correlate kernel version and Bluetooth commit history against the fixing commits 051922a, 3374ef8, 356c9d1, and ed5fcd2
Audit systems for the presence of commit 1c08108f3014 without the corresponding fix applied

Monitoring Recommendations

Enable Bluetooth HCI logging on high-value endpoints and forward captures to a centralized analysis pipeline
Alert on abnormal L2CAP reconfiguration failures paired with malformed request diagnostics from the peer
Track kernel package versions across the fleet to identify unpatched hosts exposing Bluetooth to untrusted devices

How to Mitigate CVE-2026-64127

Immediate Actions Required

Apply the upstream Linux kernel fix that replaces sizeof(pdu), &pdu with struct_size(pdu, scid, 1) and the pdu pointer as the source argument
Update to a distribution kernel that incorporates commits 051922a, 3374ef8, 356c9d1, or ed5fcd2
Restrict Bluetooth pairing to trusted devices on kernels that cannot be immediately updated

Patch Information

The fix restores the original semantics by passing the full flex-struct size via struct_size(pdu, scid, 1) and forwarding the pdu pointer as the source of the payload. Stable kernel branches receive the fix through the referenced git commits listed in the Linux Kernel Git repository.

Workarounds

Disable Bluetooth on systems that do not require it via rfkill block bluetooth or by unloading the bluetooth kernel module
Avoid pairing with untrusted peripherals, since exploitation requires a paired and connected L2CAP peer
Refrain from applications that trigger setsockopt(SOL_BLUETOOTH, BT_RCVMTU, ...) on L2CAP_MODE_EXT_FLOWCTL sockets until the kernel is patched

bash

# Configuration example
# Temporarily disable Bluetooth stack until the kernel is patched
sudo rfkill block bluetooth
sudo systemctl stop bluetooth.service
sudo systemctl disable bluetooth.service
sudo modprobe -r btusb bluetooth