CVE-2026-64127 in Linuxinfo

Summary

by MITRE • 07/19/2026

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: ecred_reconfigure: send packed pdu, not stack pointer

Commit 1c08108f3014 ("Bluetooth: L2CAP: Avoid -Wflex-array-member-not-at-end warnings") converted the on-stack request PDU in l2cap_ecred_reconfigure() from an explicit packed struct to DEFINE_RAW_FLEX(), but did not adjust the size and source-pointer arguments to l2cap_send_cmd():

- struct {
- struct l2cap_ecred_reconf_req req; - __le16 scid; - } pdu; + DEFINE_RAW_FLEX(struct l2cap_ecred_reconf_req, pdu, scid, 1); ... l2cap_send_cmd(conn, chan->ident, L2CAP_ECRED_RECONF_REQ, sizeof(pdu), &pdu);

After the conversion, DEFINE_RAW_FLEX() expands to declare an anonymous union pdu_u plus a local pointer "pdu" pointing at it. Therefore:

- sizeof(pdu) is now sizeof(struct l2cap_ecred_reconf_req *) = 8 on 64-bit (4 on 32-bit), not the 6 bytes of (mtu, mps, scid[1]).
- &pdu is the address of the local pointer's stack storage, not the address of the request payload.

l2cap_send_cmd() forwards (data, count) to l2cap_build_cmd(), which calls skb_put_data(skb, data, count). The L2CAP_ECRED_RECONFIGURE_REQ packet body therefore contains 8 bytes copied from the kernel stack starting at &pdu -- the 8 bytes overlap the pdu pointer's value, leaking a kernel stack address to the paired Bluetooth peer. The intended (mtu, mps, scid) fields are not transmitted at all, so the peer rejects the request as malformed and the L2CAP_ECRED_RECONFIGURE feature itself has been broken for the local-side initiator since the introducing commit landed.

The sibling site l2cap_ecred_conn_req() in the same commit was converted correctly (sizeof(*pdu) + len, pdu); only this site was missed.

Restore the original semantics: pass the full flex-struct size via struct_size(pdu, scid, 1) and the pdu pointer (the struct address) as the source.

Validated on a stock 7.0-based host kernel via the real call path: setsockopt(SOL_BLUETOOTH, BT_RCVMTU, ...) on a BT_CONNECTED L2CAP_MODE_EXT_FLOWCTL socket emits an L2CAP_ECRED_RECONFIGURE_REQ whose body is 8 bytes (the on-stack pdu local's value) rather than the expected 6. Three captures from fresh socket / fresh hciemu peer on the same host -- low bytes vary per call, high 0xffff confirms a kernel virtual address (KASLR-randomised stack slot, not a fixed string):

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

After this patch the body is 6 bytes carrying the expected little-endian (mtu, mps, scid).

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 07/19/2026

The vulnerability described involves a critical flaw in the Linux kernel's Bluetooth implementation within the L2CAP layer, specifically affecting the extended flow control reconfiguration mechanism. This issue stems from an improper conversion of a stack-based structure during a code refactoring effort aimed at eliminating compiler warnings related to flexible array members. The commit 1c08108f3014 introduced a change that converted an explicit packed struct into a DEFINE_RAW_FLEX macro, which inadvertently altered how the data is handled when sent over the Bluetooth connection.

The technical flaw manifests in the l2cap_ecred_reconfigure() function where the size and pointer arguments passed to l2cap_send_cmd() are no longer correctly aligned with the intended data structure. Prior to the fix, the code correctly calculated the size of the PDU as sizeof(pdu) and used &pdu to reference the actual data payload. After the conversion, DEFINE_RAW_FLEX generated an anonymous union along with a local pointer named pdu that points to this union rather than directly to the data. As a result, the size calculation now returns the size of a pointer instead of the actual structure size, and the address used for data transmission points to the stack location holding the pointer itself rather than the payload data.

This misconfiguration leads to two primary security implications. First, kernel stack memory addresses are leaked to remote Bluetooth peers through the transmission of 8 bytes of stack data in the L2CAP_ECRED_RECONFIGURE_REQ packet body, which should contain only 6 bytes of structured data (mtu, mps, scid). Second, the legitimate fields that were meant to be transmitted are completely omitted from the packet, causing remote peers to reject the malformed reconfiguration request. This effectively breaks the entire L2CAP extended flow control reconfiguration feature for local initiators.

The vulnerability aligns with CWE-125 Out-of-bounds Read and CWE-200 Information Exposure, as it exposes kernel memory contents through network traffic and fails to properly validate data structures. From an ATT&CK perspective, this maps to T1059 Command and Scripting Interpreter and T1566 Impair Defenses, since the flaw could potentially allow adversaries to gain information about kernel memory layout or disrupt Bluetooth communication services.

The fix restores the original behavior by correctly calculating the full flexible structure size using struct_size(pdu, scid, 1) and passing the proper pointer to the structure address rather than the stack location of the pointer variable. This ensures that only the intended data fields are transmitted while preventing kernel memory leakage. The validation demonstrates that before the patch, three separate captures showed 8-byte packet bodies containing kernel virtual addresses, confirming the stack leak, whereas after the patch, the correct 6-byte structures are transmitted with proper field values. This vulnerability affects all Linux systems running kernel versions where commit 1c08108f3014 was introduced and requires immediate patching to prevent both information disclosure and service disruption in Bluetooth communications.

Responsible

Linux

Reservation

07/19/2026

Disclosure

07/19/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!