CVE-2026-46123

Technical summary

The virtbt_rx_work() function in the virtio Bluetooth driver processes incoming packets from a virtio queue without properly validating the length field reported by the device. The receive buffer is allocated as exactly 1000 bytes via alloc_skb() and exposed to the device via sg_init_one(), but the driver accepts any reported length up to skb_tailroom(skb), which may be substantially larger due to allocator overhead. This allows a malicious backend to report used.len values between 1001 and skb_tailroom(skb), causing skb_put() to advance the buffer pointer into uninitialized kernel heap memory never written by the device. Additionally, the driver accepts zero-length completions, allowing virtbt_rx_handle() to read the packet type byte from uninitialized memory. The fix enforces a strict VIRTBT_RX_BUF_SIZE constant across allocation, device exposure, and validation, and rejects zero-length frames with rate-limited error logging to prevent log flooding from an untrusted backend.

Business impact

This vulnerability enables information disclosure of kernel heap memory in virtualized Linux environments where an attacker controls the virtual Bluetooth device backend. In cloud or multi-tenant hypervisor scenarios, a compromised guest VM or rogue hypervisor component can read sensitive data from the host kernel or other guest kernels' memory. The denial-of-service angle (via uninitialized data exposure triggering crashes or undefined behavior) can disrupt availability. Organizations running unpatched Linux kernels with virtio Bluetooth support in virtualized infrastructure face risk of cross-VM data leakage and service interruption.

Affected systems

The Linux kernel is affected across multiple stable and development branches. The vulnerability is specific to systems with virtio Bluetooth backend support enabled—primarily virtualized environments (KVM, QEMU, Xen, Hyper-V, etc.) where Linux guests use paravirtualized Bluetooth devices. The issue does not affect bare-metal systems or systems without virtio Bluetooth driver compiled or loaded. Affected kernel versions range from the introduction of virtio Bluetooth support through the unpatched versions prior to the published fix. Verify the exact affected versions and patch availability in the official Linux kernel security advisories and your distribution's security updates.

Exploitability

Exploitation requires local access to a Linux system with virtio Bluetooth backend support active and the ability to control or compromise the virtio device backend—typically requiring hypervisor-level or privileged guest-level access. The attack is not remotely exploitable. The vulnerability is not present in CISA's Known Exploited Vulnerabilities (KEV) catalog and no public exploit code has been disclosed. However, the root cause (unchecked device-reported lengths) is a well-understood class of vulnerability (similar to CVE patterns in USB and 9p transport), making proof-of-concept development straightforward for threat actors with relevant access. The impact is deterministic: a malicious backend can reliably leak kernel memory or trigger undefined behavior.

Remediation

Apply the upstream Linux kernel patch that defines and enforces VIRTBT_RX_BUF_SIZE as a compile-time constant, reuses it consistently in buffer allocation and device exposure, and adds explicit validation and zero-length rejection in virtbt_rx_work(). Monitor your Linux distribution's security advisories for backported patches to stable kernel branches. Organizations should prioritize patching on virtualized infrastructure, particularly in shared or multi-tenant environments. Additionally, review and restrict hypervisor access controls to limit who can provision or modify virtual device backends.

Patch guidance

Check your Linux distribution's security advisory portal for kernel updates addressing CVE-2026-46123. Typical remediation paths include: (1) upgrade to a patched stable kernel version released by your distribution after the published CVE date (verify against the vendor advisory for exact version numbers); (2) apply a targeted security backport if available for your current kernel series; (3) recompile the kernel from upstream sources with the fix applied. Verify the patch presence by confirming VIRTBT_RX_BUF_SIZE constant definition and the length validation logic in virtbt_rx_work(). Test virtual Bluetooth device functionality post-patch to ensure no regressions.

Detection guidance

Monitor kernel logs for rate-limited error messages originating from the Bluetooth virtio backend layer reporting invalid length values—these indicate attempted exploitation or device malfunction. Inspect running kernel configuration to confirm whether CONFIG_BT_VIRTIO is enabled; if not, the system is not vulnerable. In virtualized environments, audit hypervisor logs for anomalous device backend behavior or privilege escalation attempts. For forensic investigation, capture kernel memory dumps and correlate them with virtio device state at time of incident. Host-based integrity monitoring tools should flag unexpected kernel memory reads from unprivileged contexts near virtio device driver code.

Why prioritize this

This vulnerability merits prompt attention due to its HIGH CVSS score (7.7), local but deterministic exploitability, and direct impact on memory confidentiality and availability in virtualized infrastructure. In multi-tenant cloud or hypervisor environments, cross-VM data leakage is a critical concern. The vulnerability class (unchecked device-reported lengths) is well-established and unlikely to have undiscovered variants, justifying aggressive patching. However, attacks require hypervisor or privileged guest compromise, limiting the exposed attack surface compared to remote or network-facing vulnerabilities. Prioritize patching for virtualized environments over bare-metal systems.

Risk score, explained

The CVSS 3.1 score of 7.7 (HIGH) reflects a local attack with no special user interaction required, low complexity, high confidentiality impact (kernel memory disclosure), high availability impact (potential denial of service from uninitialized data), and no integrity risk from this specific vector. The attack vector is local because it requires control of the virtio backend, which is typically available only to hypervisor-level or privileged guest processes. The score appropriately penalizes the memory safety violation and potential for information disclosure while acknowledging the restricted attack surface.

Frequently asked questions