CVE-2026-43062: Bluetooth L2CAP Type Confusion in l2cap_ecred_reconf_rsp()

Overview

CVE	CVE-2026-43062
Component	net/bluetooth/l2cap_core.c (l2cap_ecred_reconf_rsp())
Introduced	15f02b910562
Fix	8c5c181c2693
Class	CWE-843 (Type Confusion)
CVSS v3.1	7.1 (High) -- CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L
Found and patched by	Lukas Johannes Moeller (@JohannesLks)

TL;DR

The ECRED reconfiguration response parser casts packet data to the wrong response structure. That makes the length check too strict and reads the result field from offset 6 even though the real response is a 2-byte structure. The result is a remotely triggerable Bluetooth protocol-state bug rather than a proven memory-corruption primitive.

Root Cause

The vulnerable handler uses the connection response type:

struct l2cap_ecred_conn_rsp *rsp = (void *) data;

if (cmd_len < sizeof(*rsp))   // 8 bytes
    return -EPROTO;

result = __le16_to_cpu(rsp->result); // offset 6

The packet being parsed is an ECRED reconfiguration response:

struct l2cap_ecred_reconf_rsp {
    __le16 result;
};

That mismatch creates two separate parser errors: valid 2-byte responses are rejected, and longer attacker-controlled packets can steer the result value through bytes that are not the result field.

Impact

• Remote Bluetooth peer can disrupt ECRED MTU/MPS reconfiguration without pairing.
• No out-of-bounds access is required for exploitation; the bug is type confusion and state-machine correctness.
• Security severity is lower than a kernel memory corruption issue, but the finding is still worth publishing because it sits in unauthenticated Bluetooth parsing and had a one-line, high-confidence fix.

Fix

- struct l2cap_ecred_conn_rsp *rsp = (void *) data;
+ struct l2cap_ecred_reconf_rsp *rsp = (void *) data;

After the type correction, sizeof(*rsp) matches the wire format and rsp->result is read from the correct offset.