PT-2026-44246 · Linux · Linux
Published
2026-05-28
·
Updated
2026-05-28
·
CVE-2026-46123
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: clamp rx length before skb put
virtbt rx work() calls skb put(skb, len) where len comes directly
from virtqueue get buf() with no validation against the buffer we
posted to the device. The RX skb is allocated in virtbt add inbuf()
and exposed to virtio as exactly 1000 bytes via sg init one().
Checking len against skb tailroom(skb) is not sufficient because
alloc skb() 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 skb tailroom(skb), causing skb put()
to include uninitialized kernel heap bytes that were never written by
the device.
The same path also accepts len == 0, in which case skb put(skb, 0)
leaves the skb empty but virtbt rx handle() still reads the pkt type
byte from skb->data, consuming uninitialized memory.
Define VIRTBT RX BUF SIZE once and reuse it in alloc skb() and
sg init one(), and gate virtbt rx work() 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 virtbt rx handle().
Use bt dev err 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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux