In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: virtiobt: clamp rx length before skbput
virtbtrxwork() calls skbput(skb, len) where len comes directly from virtqueuegetbuf() with no validation against the buffer we posted to the device. The RX skb is allocated in virtbtaddinbuf() and exposed to virtio as exactly 1000 bytes via sginit_one().
Checking len against skbtailroom(skb) is not sufficient because allocskb() can leave more tailroom than the 1000 bytes actually handed to the device. A malicious or buggy backend can therefore report used.len between 1001 and skbtailroom(skb), causing skbput() to include uninitialized kernel heap bytes that were never written by the device.
The same path also accepts len == 0, in which case skbput(skb, 0) leaves the skb empty but virtbtrxhandle() still reads the pkttype byte from skb->data, consuming uninitialized memory.
Define VIRTBTRXBUFSIZE once and reuse it in allocskb() and sginitone(), and gate virtbtrxwork() on that same constant so the bound checked matches the buffer actually exposed to the device. Reject used.len == 0 in the same gate so an empty completion can no longer reach virtbtrxhandle().
Use btdeverr_ratelimited() because the length value comes from an untrusted backend that can otherwise flood the kernel log.
Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened the USB 9p transport against unchecked device-reported length.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/46xxx/CVE-2026-46123.json"
}