{"id":"AZL-93704","summary":"CVE-2026-64403 affecting package kernel for versions less than 6.6.145.2-1","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: validate option length before reading conf opt value\n\nl2cap_get_conf_opt() derives the option length from the\nattacker-controlled opt-\u003elen field and immediately dereferences\nopt-\u003eval (as u8, get_unaligned_le16() or get_unaligned_le32(), or a\nraw pointer for the default case) before any caller has confirmed\nthat opt-\u003elen bytes are present in the buffer. The callers\n(l2cap_parse_conf_req(), l2cap_parse_conf_rsp() and\nl2cap_conf_rfc_get()) only detect a malformed option afterwards, once\nthe running length has gone negative, by which point the\nout-of-bounds read has already executed.\n\nAn existing post-hoc length check keeps the garbage value from being\nconsumed, so this is not a data leak in the current control flow. It\nis still a validate-after-use ordering bug: up to 4 bytes are read\npast the end of the buffer before it is known to contain them, and it\nis fragile to future changes in the callers.\n\nFix it at the source. Pass the end of the buffer into\nl2cap_get_conf_opt() and refuse to touch opt-\u003eval unless the full\noption (header + value) fits. Each caller computes an end pointer\nonce before the loop and checks the return value directly instead of\ninferring the error from a negative length.","modified":"2026-08-28T17:48:13.120267673Z","published":"2026-07-25T10:17:23Z","upstream":["CVE-2026-64403"],"references":[{"type":"WEB","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-64403"}],"affected":[{"package":{"name":"kernel","ecosystem":"Azure Linux:3","purl":"pkg:rpm/azure-linux/kernel"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.145.2-1"}]}],"database_specific":{"source":"https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-93704.json"}}],"schema_version":"1.9.0"}