CVE-2026-72334

This CVE exposes a fundamental flaw in how the Linux kernel's Bluetooth ISO implementation handles controller input: it was built on assumptions about what controllers would send, rather than what the Bluetooth specification permits them to send. The three failure modes—a memory leak when ISO_CONT ends, a kernel panic on oversized ISO_END, and silent acceptance of undersized ISO_END—aren't sophisticated attack vectors. They're the fingerprints of a state machine that breaks when a spec-compliant controller behaves within allowed parameters. The fix adds explicit state tracking via conn->rx_skb and consolidates the CONT/END handling paths, which tells you the original code treated controller behavior as a deterministic contract rather than a variable input. That contract was never documented, reviewed against the full diversity of controller implementations, or tested against edge cases the spec explicitly allows (including empty packets in §5.4.5). When controllers sent what the spec permits but the kernel didn't expect, different code paths failed in different ways. The CVSS 8.8 reflects the technical severity—a kernel panic from malformed input is serious—but the EPSS score of 0.00341 tells you this isn't being exploited in the wild. Exploiting it requires a paired Bluetooth connection, meaning the attacker already has the access that makes this a secondary concern in most threat models. The real issue isn't whether this specific bug will be weaponized; it's whether the kernel treats controller firmware as trusted by default, and how many other ISO state machine assumptions remain untested. Patch immediately. Beyond that, treat controller output as untrusted input requiring the same defensive posture you apply to network packets—this CVE shows we're not there yet, and the pattern of state machine fixes across ISO, HCI, and USB suggests the problem is systemic rather than isolated.

Reviewed through automated stages and approved by a human before publication.