CVE-2026-64403

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

Bluetooth: L2CAP: validate option length before reading conf opt value

l2cap_get_conf_opt() derives the option length from the

attacker-controlled opt->len field and immediately dereferences

opt->val (as u8, get_unaligned_le16() or get_unaligned_le32(), or a

raw pointer for the default case) before any caller has confirmed

that opt->len bytes are present in the buffer. The callers

(l2cap_parse_conf_req(), l2cap_parse_conf_rsp() and

l2cap_conf_rfc_get()) only detect a malformed option afterwards, once

the running length has gone negative, by which point the

out-of-bounds read has already executed.

An existing post-hoc length check keeps the garbage value from being

consumed, so this is not a data leak in the current control flow. It

is still a validate-after-use ordering bug: up to 4 bytes are read

past the end of the buffer before it is known to contain them, and it

is fragile to future changes in the callers.

Fix it at the source. Pass the end of the buffer into

l2cap_get_conf_opt() and refuse to touch opt->val unless the full

option (header + value) fits. Each caller computes an end pointer

once before the loop and checks the return value directly instead of

inferring the error from a negative length.