PT-2026-44309 · Linux · Linux

Published

2026-05-28

·

Updated

2026-05-28

·

CVE-2026-46186

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.

Related Identifiers

CVE-2026-46186

Affected Products

Linux