The underread in hci_read_codec_capabilities() is a single-byte off-by-one: the code validates that caps->len fits in the remaining skb space but forgets that reading the length byte itself consumes one byte. The fix is adding '+1' to the validation check. That's the mechanical detail. What matters more is what this reveals about kernel Bluetooth's threat model and why it matters for your deployments.
This vulnerability lives in the path between receiving a controller response and populating the kernel's codec capability list—the data structure that governs how audio gets routed through the Bluetooth stack. When a malformed controller sends truncated codec data, the underread causes the parser to record a capability length that exceeds the actual payload, then copies data from beyond the advertised boundary. The consequence isn't a generic buffer overflow; it's external-controller-controlled data bleeding into kernel audio routing state. Corrupted codec negotiation state can persist across sessions and be readable back through subsequent HCI commands, creating a stateful confusion primitive that doesn't require winning the memory layout lottery on every invocation.
Three things to verify in your environment: First, check whether your kernel version includes the fix (look for the '+1' adjustment in the bounds check before the memcpy of codec capabilities). Second, audit your Bluetooth controller firmware—this bug only triggers when a controller sends malformed length-prefixed responses, which should be caught by Bluetooth qualification testing but clearly isn't in some firmware. Third, assess whether active Bluetooth audio sessions could be affected by corrupted codec state; if you have persistent connections, the lingering impact matters more than the initial underread.
The deeper pattern here is that length-prefixed parsing in kernel network code has produced this exact off-by-one error repeatedly across two decades—the same '+1' fix has been applied to L2CAP, USB descriptors, ATM adaptation, and now Bluetooth codec capabilities. Each CVE treats it as an isolated incident rather than a symptom of a parsing paradigm that keeps expressing the same recessive flaw. The kernel has no institutionalized guard against this specific off-by-one in any new length-prefixed parser. Consider whether your code review process has specific checks for the length-byte footprint in TLV-style validation, and whether fuzzing coverage for Bluetooth controller responses is adequate—this isn't just a kernel bug, it's a gap in the controller firmware ecosystem that the kernel now must defend against.