CVE-2026-64403

Technical Description

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

Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

References