CVE-2026-64403

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: validate option length before reading conf opt value<br /> <br /> l2cap_get_conf_opt() derives the option length from the<br /> attacker-controlled opt-&gt;len field and immediately dereferences<br /> opt-&gt;val (as u8, get_unaligned_le16() or get_unaligned_le32(), or a<br /> raw pointer for the default case) before any caller has confirmed<br /> that opt-&gt;len bytes are present in the buffer. The callers<br /> (l2cap_parse_conf_req(), l2cap_parse_conf_rsp() and<br /> l2cap_conf_rfc_get()) only detect a malformed option afterwards, once<br /> the running length has gone negative, by which point the<br /> out-of-bounds read has already executed.<br /> <br /> An existing post-hoc length check keeps the garbage value from being<br /> consumed, so this is not a data leak in the current control flow. It<br /> is still a validate-after-use ordering bug: up to 4 bytes are read<br /> past the end of the buffer before it is known to contain them, and it<br /> is fragile to future changes in the callers.<br /> <br /> Fix it at the source. Pass the end of the buffer into<br /> l2cap_get_conf_opt() and refuse to touch opt-&gt;val unless the full<br /> option (header + value) fits. Each caller computes an end pointer<br /> once before the loop and checks the return value directly instead of<br /> inferring the error from a negative length.