CVE-2026-46123

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: virtio_bt: clamp rx length before skb_put<br /> <br /> virtbt_rx_work() calls skb_put(skb, len) where len comes directly<br /> from virtqueue_get_buf() with no validation against the buffer we<br /> posted to the device. The RX skb is allocated in virtbt_add_inbuf()<br /> and exposed to virtio as exactly 1000 bytes via sg_init_one().<br /> <br /> Checking len against skb_tailroom(skb) is not sufficient because<br /> alloc_skb() can leave more tailroom than the 1000 bytes actually<br /> handed to the device. A malicious or buggy backend can therefore<br /> report used.len between 1001 and skb_tailroom(skb), causing skb_put()<br /> to include uninitialized kernel heap bytes that were never written by<br /> the device.<br /> <br /> The same path also accepts len == 0, in which case skb_put(skb, 0)<br /> leaves the skb empty but virtbt_rx_handle() still reads the pkt_type<br /> byte from skb-&gt;data, consuming uninitialized memory.<br /> <br /> Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and<br /> sg_init_one(), and gate virtbt_rx_work() on that same constant so<br /> the bound checked matches the buffer actually exposed to the device.<br /> Reject used.len == 0 in the same gate so an empty completion can<br /> no longer reach virtbt_rx_handle().<br /> <br /> Use bt_dev_err_ratelimited() because the length value comes from an<br /> untrusted backend that can otherwise flood the kernel log.<br /> <br /> Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer<br /> overflow in USB transport layer"), which hardened the USB 9p<br /> transport against unchecked device-reported length.