CVE-2026-46186

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: virtio_bt: validate rx pkt_type header length<br /> <br /> virtbt_rx_handle() reads the leading pkt_type byte from the RX skb<br /> and forwards the remainder to hci_recv_frame() for every<br /> event/ACL/SCO/ISO type, without checking that the remaining payload<br /> is at least the fixed HCI header for that type.<br /> <br /> After the preceding patch bounds the backend-supplied used.len to<br /> [1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches<br /> hci_recv_frame() with skb-&gt;len already pulled to 0. If the byte<br /> happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification<br /> fast-path in hci_dev_classify_pkt_type() dereferences<br /> hci_acl_hdr(skb)-&gt;handle whenever the HCI device has an active<br /> CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of<br /> uninitialized RX-buffer data. The same hazard exists for every<br /> packet type the driver accepts because none of the switch cases in<br /> virtbt_rx_handle() check skb-&gt;len against the per-type minimum HCI<br /> header size before handing the frame to the core.<br /> <br /> After stripping pkt_type, require skb-&gt;len to cover the fixed<br /> header size for the selected type (event 2, ACL 4, SCO 3, ISO 4)<br /> before calling hci_recv_frame(); drop ratelimited otherwise.<br /> Unknown pkt_type values still take the original kfree_skb() default<br /> path.<br /> <br /> Use bt_dev_err_ratelimited() because both the length and pkt_type<br /> values come from an untrusted backend that can otherwise flood the<br /> kernel log.