CVE-2026-46186

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: virtio_bt: validate rx pkt_type header length

virtbt_rx_handle() reads the leading pkt_type byte from the RX skb

and forwards the remainder to hci_recv_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, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches

hci_recv_frame() with skb->len already pulled to 0. If the byte

happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification

fast-path in hci_dev_classify_pkt_type() dereferences

hci_acl_hdr(skb)->handle whenever the HCI device has an active

CIS_LINK, BIS_LINK, or PA_LINK 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

virtbt_rx_handle() check skb->len against the per-type minimum HCI

header size before handing the frame to the core.

After stripping pkt_type, require skb->len to cover the fixed

header size for the selected type (event 2, ACL 4, SCO 3, ISO 4)

before calling hci_recv_frame(); drop ratelimited otherwise.

Unknown pkt_type values still take the original kfree_skb() default

path.

Use bt_dev_err_ratelimited() because both the length and pkt_type

values come from an untrusted backend that can otherwise flood the

kernel log.