CVE-2026-78117: Race condition on shared HCI TX descriptor in the Infineon PSOC 6 BLESS Bluetooth driver can leak adjacent memory over the air
The Infineon PSOC 6 BLESS HCI driver in drivers/bluetooth/hci/hciinfineonpsoc6bless.c stored the outgoing HCI packet descriptor in a file-scope variable, static cystcblehcitxpacketinfot hcitxpkt. psoc6blesssend() cleared and populated that descriptor's packetType, dataLength and data fields before acquiring psoc6blessoperationsem, so the driver's serialising semaphore protected only the call into CyBLESoftHciSendAppPkt() and not the shared state that call reads.
The Bluetooth host does not guarantee a single HCI sender. Most transmissions are funnelled through the cooperative TX-processor work queue, but bthcicmdsend() deliberately bypasses btdev.cmdtxqueue for BTHCIOPHOSTNUMCOMPLETEDPACKETS and calls btsend() directly from the caller's thread; that caller is bthcihostnumcompletedpackets(), the aclinpool destroy callback, which runs on whichever thread drops the last reference to a received ACL buffer. CONFIGBTHCIACLFLOWCONTROL defaults to y on this driver's boards, and an application that returns -EINPROGRESS from its L2CAP recv callback and later calls btl2capchanrecvcomplete() performs that unref from its own preemptible thread. A remote peer that generates Bluetooth traffic concurrently with the device's own transmissions raises the collision rate.
When two senders interleave, the semaphore holder can hand the controller a descriptor whose dataLength comes from one netbuf and whose data pointer comes from another — or one whose buffer has already been returned to its pool. The controller then copies and transmits up to a full HCI/ACL payload starting at a shorter or recycled buffer, disclosing adjacent RAM contents to the connected peer; other interleavings duplicate one HCI packet and silently drop another, disrupting the link. The driver only reads through the shared descriptor, so no memory corruption or write primitive results, and the disclosed bytes are not attacker-chosen. The fix makes the descriptor a local variable in psoc6blesssend(), removing the shared state; CyBLESoftHciSendAppPkt() copies the packet before returning, so it need not outlive the call.
Affected Software
Event History
Frequently Asked Questions
Which deployments are most likely to expose the race?
The relevant path is enabled by default on this driver's boards because CONFIG_BT_HCI_ACL_FLOW_CONTROL defaults to y. Exposure additionally depends on an application returning -EINPROGRESS from an L2CAP receive callback and later calling bt_l2cap_chan_recv_complete() from a preemptible thread.
What concurrency is required for the issue to occur?
A host-number-completed-packets command must be sent directly from the thread that drops the final reference to a received ACL buffer while another transmission uses the shared descriptor. The normal cooperative TX-processor queue does not guarantee that all HCI sends are serialized with this direct-send path.
How can I assess whether our code has the vulnerable behavior?
Check whether the driver uses a file-scope hci_tx_pkt descriptor and populates its packetType, dataLength, and data fields before taking psoc6_bless_operation_sem. Also check whether ACL flow control is enabled and whether application L2CAP receive handling defers completion with -EINPROGRESS followed by bt_l2cap_chan_recv_complete().