Bluetooth: virtio_bt: clamp rx length before skb_put

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.