CVE-2026-11893

The CVSS 5.9 rating for this BLE driver vulnerability misses the real threat surface. While the CVE describes controller TX failures under heavy link load as the trigger, a significantly lower-bar path exists through malformed H:4 packets — a software-layer artifact that doesn't require manipulating radio conditions at all. If an authenticated BLE peer can inject unexpected HCI command types (which the CVE preconditions suggest is the case), the attack becomes: authenticated connection → HCI command injection → driver error path → double-unref. That's not indirect. That's a straightforward exploitation chain from a standard paired device. The more serious issue isn't the crash — it's the cascading pool corruption. The driver's error path unconditionally frees a buffer through a shared exit label, but that buffer's parent remains queued on a connection object. The result is a double-free that poisons the net_buf pool, and since these pools are shared across the Bluetooth host stack, logging paths, and HCI event queues, the corruption propagates downstream into unrelated code. The 'non-deterministic downstream behavior' in the CVE description is accurate: a use-after-free whose symptoms appear three operations later, in code that never touched the trigger path, is far worse than a clean crash because detection and attribution become nearly impossible without pool debugging most embedded deployments don't run. There's a genealogical dimension here: this is structurally identical to CVE-2021-3453 in the STM32WB HCI driver (double-unref on send() error path). The postmortem explicitly flagged convergent error-label patterns as the anti-pattern to audit — yet the same flaw reappeared in a different vendor driver. This suggests the ecosystem addressed a single commit rather than the pattern, and every automated refactoring pass touching HCI driver exit labels since then has been operating against a known hazard that never got structurally eliminated. The regression timeline matters. If the vulnerable shared exit label came from a recent 'cleanup' refactoring, the vulnerability may be a regression rather than a long-standing flaw — meaning shipped firmware may not all be affected, but the window between that commit and CVE disclosure is the actual exposure period. Verify when the driver last saw substantial changes. For defenders: audit whether your deployment uses Bouffalo Lab BLE controllers with the Zephyr bt_hci_driver; check driver version against recent net_buf refactoring commits; verify whether HCI command filtering exists at the controller interface layer (this determines if the H:4 path is viable); and treat any BLE-connected device as a potential trigger vector, not just a crash target. The pool corruption is the real blast radius — consider whether shared buffer pools across your system justify treating this as a heap corruption issue rather than a bounded DoS.

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