CVE-2026-46123

What it actually does

CVE-2026-46123 is a Linux kernel virtio Bluetooth receive-path flaw in virtbt_rx_work(). The driver accepts a device/backend-reported receive length from virtqueue_get_buf() and passes it to skb_put() without validating it against the 1000-byte buffer actually exposed to the virtio device. A malicious or faulty virtio Bluetooth backend can report a length larger than the shared RX buffer, causing the kernel to treat unwritten skb memory as packet data and potentially disclose uninitialized kernel heap contents. The path also accepts zero-length completions, allowing virtbt_rx_handle() to read a packet type byte from uninitialized memory. The practical impact is primarily kernel memory disclosure and potential local denial of service in systems that expose virtio Bluetooth to an untrusted or compromised backend.

Why it matters to the business

Organizations using Linux guests or systems with virtio Bluetooth enabled may be exposed to kernel memory disclosure or instability if the virtio backend, hypervisor-side device implementation, or another local component that can influence the virtqueue is malicious or compromised. The issue is local rather than remotely exploitable over the network, EPSS is currently very low, and it is not listed in CISA KEV, so broad internet-scale exploitation is unlikely. However, in virtualized, sandboxed, or multi-tenant environments where device backends are part of the isolation boundary, this can weaken guest/kernel confidentiality and availability assumptions.

How an attack unfolds

An attacker needs the ability to act as, compromise, or influence the virtio Bluetooth backend presented to a Linux kernel using the virtio_bt driver. The guest driver posts an RX skb-backed buffer of 1000 bytes to the virtqueue. Instead of returning a valid completion length, the malicious backend reports a crafted used length greater than the buffer actually supplied, or reports zero. For oversized lengths, the kernel calls skb_put() and expands the skb to include bytes that were never written by the backend, exposing uninitialized kernel heap data to subsequent Bluetooth packet handling paths and potentially to logs, consumers, or attacker-observable behavior. For zero-length completions, packet handling proceeds on an empty skb and reads an uninitialized packet type byte, which may trigger unpredictable behavior or a crash. Repeated malformed completions may also cause error activity and service instability, although the fix rate-limits related kernel logging.

How to fix it

Upgrade the Linux kernel to a version that includes the virtio_bt fix that defines a single VIRTBT_RX_BUF_SIZE, allocates and exposes the same buffer size, rejects used.len values greater than that size, and rejects used.len == 0 before packet handling. Because no exact fixed versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory and prioritize systems where virtio Bluetooth is enabled in virtualized environments. If immediate patching is not possible, reduce exposure by disabling virtio Bluetooth where not required, removing the virtio_bt module from guest images, blocking module autoload where operationally safe, and avoiding untrusted or externally controlled virtio device backends.

How to confirm the fix worked

Confirm the running kernel includes the vendor backport or upstream fix for the virtio_bt receive length validation. Validate by checking the installed kernel package changelog or vendor advisory for the virtio Bluetooth skb_put receive length fix, then reboot into the patched kernel. On hosts where source or debug symbols are available, confirm the virtio_bt receive path rejects zero-length completions and lengths above VIRTBT_RX_BUF_SIZE before calling skb_put() or virtbt_rx_handle(). Operationally, verify whether the virtio_bt module is loaded with lsmod or modinfo and confirm that systems not requiring virtio Bluetooth have the module disabled or absent. Exposure is limited if virtio_bt is not loaded and no virtio Bluetooth device is presented.

Typical attack path

1. Identify a Linux system or guest where the virtio Bluetooth driver is present and active.
2. Gain control over, compromise, or emulate the virtio Bluetooth backend or device model that supplies RX virtqueue completions.
3. Wait for or trigger the guest driver to post a 1000-byte receive buffer via the virtqueue.
4. Return a malformed used.len value, either 0 or a value greater than 1000 but still acceptable to the pre-fix skb tailroom check.
5. Cause virtbt_rx_work() to call skb_put() with the untrusted length and pass the resulting skb to Bluetooth receive handling.
6. Leverage the resulting uninitialized memory read for kernel information disclosure or to induce guest kernel instability/denial of service.

How to detect it

Look for evidence that virtio Bluetooth is present and that malformed RX completions caused driver errors, Bluetooth receive anomalies, or kernel instability. Useful sources include kernel ring buffer output, systemd journal kernel logs, syslog/kern.log, hypervisor or virtual device backend logs, crash dumps, and monitoring alerts for guest kernel oops/panic events. Search for virtio Bluetooth driver messages, rate-limited Bluetooth device errors referencing invalid receive lengths, warnings or stack traces involving virtbt_rx_work(), virtbt_rx_handle(), skb_put(), or Bluetooth HCI receive paths. Since exploitation requires control or compromise of the virtio Bluetooth backend and the public description does not provide a stable attacker payload or file artifact, absence of logs does not prove non-exploitation; use kernel crash dumps and backend telemetry where available to determine whether malformed used.len values were returned.

• virtbt_rx_work
• virtbt_rx_handle
• virtio_bt
• virtio_bt.ko
• Bluetooth: virtio_bt
• skb_put
• invalid rx length
• invalid RX length
• used.len
• virtqueue_get_buf
• bt_dev_err_ratelimited
• kernel: Bluetooth
• kernel: virtio_bt
• BUG: kernel NULL pointer dereference
• kernel panic
• Oops:
• Call Trace:

What your security team should do

• Inventory Linux systems and guest images for use of virtio Bluetooth or the virtio_bt kernel module.
• Prioritize patching virtualized, sandboxed, development, desktop, and multi-tenant workloads where virtio device backends may be less trusted.
• Apply vendor kernel updates and reboot into the fixed kernel; no user-space service restart alone is sufficient for a kernel driver fix.
• Disable or blacklist virtio_bt on systems that do not require virtio Bluetooth functionality.
• Review hypervisor and device-backend trust boundaries; treat a compromised virtio backend as capable of attacking guest kernel device drivers.
• Monitor kernel logs for virtio Bluetooth receive-length errors, Bluetooth stack anomalies, kernel warnings, oopses, or crashes around virtbt_rx_work and virtbt_rx_handle.
• Because this vulnerability is not KEV-listed and has low EPSS, rank it below remotely exploitable internet-facing flaws unless virtio Bluetooth is deployed in high-risk virtualization scenarios.