CVE-2026-46123
Received Received - Intake
Buffer Overflow in Linux Kernel Bluetooth VirtIO Driver

Publication date: 2026-05-28

Last updated on: 2026-05-28

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-28
Last Modified
2026-05-28
Generated
2026-05-28
AI Q&A
2026-05-28
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
What immediate steps should I take to mitigate this vulnerability?

The vulnerability is resolved by ensuring that the length of received Bluetooth data is properly validated before processing. Immediate mitigation involves updating the Linux kernel to a version that includes the fix where the buffer length is clamped and zero-length packets are rejected.

Specifically, the fix defines a constant buffer size (VIRTBT_RX_BUF_SIZE) used consistently in buffer allocation and validation, preventing uninitialized kernel memory from being exposed.

Additionally, the kernel log flooding is mitigated by rate-limiting error messages related to this issue.

  • Update your Linux kernel to the patched version released on or after 2026-05-28.
  • Avoid using vulnerable kernel versions that do not include the clamp on rx length before skb_put in the virtio_bt driver.

Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's Bluetooth virtio_bt driver. It occurs because the function virtbt_rx_work() calls skb_put(skb, len) with a length value (len) obtained from virtqueue_get_buf() without validating it against the actual buffer size posted to the device.

The RX skb buffer is allocated with exactly 1000 bytes exposed to the device, but the length len can be larger than 1000 bytes (up to the skb's tailroom), which can cause skb_put() to include uninitialized kernel heap bytes that were never written by the device.

Additionally, if len is zero, skb_put(skb, 0) leaves the skb empty, but virtbt_rx_handle() still reads from skb->data, consuming uninitialized memory. This can lead to the kernel processing uninitialized or potentially sensitive data.

The fix involves defining a constant buffer size and validating len against this size, rejecting zero-length completions, and logging errors in a rate-limited manner to prevent log flooding.


How can this vulnerability impact me? :

This vulnerability can lead to the Linux kernel including uninitialized kernel heap memory in Bluetooth data processing. This may cause information leakage of sensitive kernel memory contents.

A malicious or buggy backend device could exploit this to cause the kernel to expose uninitialized memory, potentially leading to data leakage or instability.

Furthermore, reading uninitialized memory can cause unpredictable behavior or crashes, impacting system stability and security.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart