AZL-88989

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.