In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: virtiobt: validate rx pkttype header length
virtbtrxhandle() reads the leading pkttype byte from the RX skb and forwards the remainder to hcirecv_frame() for every event/ACL/SCO/ISO type, without checking that the remaining payload is at least the fixed HCI header for that type.
After the preceding patch bounds the backend-supplied used.len to [1, VIRTBTRXBUFSIZE], a one-byte completion still reaches hcirecvframe() with skb->len already pulled to 0. If the byte happened to be HCIACLDATAPKT, the ACL-vs-ISO classification fast-path in hcidevclassifypkttype() dereferences hciaclhdr(skb)->handle whenever the HCI device has an active CISLINK, BISLINK, or PALINK connection, reading two bytes of uninitialized RX-buffer data. The same hazard exists for every packet type the driver accepts because none of the switch cases in virtbtrxhandle() check skb->len against the per-type minimum HCI header size before handing the frame to the core.
After stripping pkttype, require skb->len to cover the fixed header size for the selected type (event 2, ACL 4, SCO 3, ISO 4) before calling hcirecvframe(); drop ratelimited otherwise. Unknown pkttype values still take the original kfree_skb() default path.
Use btdeverrratelimited() because both the length and pkttype values come from an untrusted backend that can otherwise flood the kernel log.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/46xxx/CVE-2026-46186.json",
"cna_assigner": "Linux"
}