CVE-2026-46186

What it actually does

This is a Linux kernel vulnerability in the virtio Bluetooth driver receive path. The driver strips the first byte of a backend-supplied Bluetooth packet as the HCI packet type, then forwards the remaining buffer to the Bluetooth core without verifying that enough bytes remain for the fixed HCI header required by that packet type. A malicious or faulty virtio Bluetooth backend can provide a truncated packet, including a one-byte packet that leaves an empty skb after the type byte is removed. Under certain Bluetooth connection states, the kernel may read uninitialized receive-buffer data while classifying ACL/ISO traffic, and malformed packets may also trigger kernel faults or denial of service. The issue is local/adjacent to the virtualized device trust boundary: exploitation requires the ability to influence the virtio Bluetooth backend or virtual device presented to the Linux system.

Why it matters to the business

Systems using virtio Bluetooth can be destabilized by malformed packets from an untrusted or compromised virtual Bluetooth backend, potentially causing service disruption, guest kernel crashes, or exposure of small amounts of uninitialized kernel-adjacent buffer data. The primary operational risk is availability loss in Linux guests or appliances that expose virtio Bluetooth, especially where virtual device backends are controlled by less-trusted infrastructure components. The vulnerability is not currently listed in CISA KEV, has very low EPSS, and has no public exploit maturity reported, so broad internet-scale exploitation is unlikely, but affected virtualized deployments should still patch during normal kernel maintenance cycles.

How an attack unfolds

An attacker first needs a position where they can control or tamper with the virtio Bluetooth backend or virtual Bluetooth device traffic delivered to the Linux kernel. They then craft a receive completion whose first byte is a valid HCI packet type, such as ACL data, event, SCO, or ISO, but whose remaining payload is shorter than the fixed header length expected for that type. The vulnerable virtio Bluetooth receive handler removes the packet-type byte and passes the undersized skb to the Bluetooth core. If the system has relevant Bluetooth state, such as active CIS, BIS, or PA links for the ACL-versus-ISO classification path, the Bluetooth core may dereference fields that are not present in the skb and read uninitialized buffer bytes. Depending on kernel state, hardening, and traffic patterns, this can result in information exposure, warnings, crashes, or denial of service. The fixed behavior is to reject undersized packets before they reach hci_recv_frame().

How to fix it

Upgrade to a Linux kernel build that includes the virtio Bluetooth fix validating minimum HCI header lengths after the packet-type byte is stripped. The corrected driver drops malformed packets unless the remaining skb length is at least 2 bytes for HCI event packets, 4 bytes for ACL packets, 3 bytes for SCO packets, and 4 bytes for ISO packets. No exact fixed package versions were provided in the input, so use the fixed kernel versions supplied by the relevant Linux distribution, appliance vendor, cloud image provider, or upstream stable kernel advisory. If immediate patching is not possible, reduce exposure by disabling unused Bluetooth support, preventing loading of the virtio_bt module where not required, removing virtual Bluetooth devices from guest configurations, and ensuring only trusted hypervisor or virtual-device backends can present virtio Bluetooth traffic to guests.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the patch for virtbt_rx_handle() that checks skb->len against the fixed HCI header size before calling hci_recv_frame(). Validate at the package level using the distribution advisory or changelog for the installed kernel, and at runtime by checking whether virtio Bluetooth is present or loaded only where required. Exposure can be assessed by looking for the virtio_bt driver/module, virtio Bluetooth devices, and Bluetooth HCI activity on Linux systems. For high-assurance validation, review the built kernel source or vendor patch metadata for the added per-packet-type length checks in the virtio Bluetooth RX path, then reboot into the fixed kernel and confirm the vulnerable kernel is no longer running.

Typical attack path

1. Gain the ability to influence the virtio Bluetooth backend, virtual device implementation, or host-to-guest Bluetooth packet delivery path.
2. Identify a Linux guest or system using the virtio_bt driver and Bluetooth HCI receive path.
3. Send a malformed virtio Bluetooth RX packet containing only a packet-type byte or a payload shorter than the required HCI header size.
4. Use a valid HCI packet type such as event, ACL, SCO, or ISO so the vulnerable switch path forwards the truncated skb to the Bluetooth core.
5. Trigger Bluetooth core parsing or packet classification on the undersized skb.
6. Cause uninitialized-buffer reads, kernel warnings, or a kernel crash/denial of service depending on system state and kernel configuration.

How to detect it

Retrospective detection should focus on kernel telemetry and virtualization-layer evidence rather than network logs, because exploitation occurs through the virtio Bluetooth device path rather than normal IP traffic. Review dmesg, journald, syslog, kdump/vmcore records, hypervisor logs, and guest kernel crash reports for Bluetooth HCI parsing errors, kernel oopses, WARN traces, slab/KASAN reports, or panics involving virtbt_rx_handle(), hci_recv_frame(), hci_dev_classify_pkt_type(), hci_acl_hdr(), or virtio_bt. Correlate events with unexpected guest resets, crashes, or host-side virtual device errors. Look for systems where virtio_bt was loaded even though Bluetooth is not expected. If kernel memory sanitizers or crash dump analysis are available, inspect traces for out-of-bounds or uninitialized reads in Bluetooth HCI classification paths after undersized skb processing. Absence of these artifacts does not prove non-exploitation because malformed packets may be dropped silently on fixed kernels and older vulnerable kernels may not log every short-frame condition.

• virtbt_rx_handle
• hci_recv_frame
• hci_dev_classify_pkt_type
• hci_acl_hdr
• virtio_bt
• Bluetooth: virtio_bt
• virtio bluetooth
• skb->len
• HCI_ACLDATA_PKT
• HCI_EVENT_PKT
• HCI_SCODATA_PKT
• HCI_ISODATA_PKT
• /sys/bus/virtio/drivers/virtio_bt
• /sys/module/virtio_bt
• kernel: Bluetooth
• kernel: virtio_bt
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• kernel panic
• KASAN
• use-after-free
• uninitialized
• Oops

What your security team should do

• Prioritize patching Linux systems that use virtio Bluetooth, especially virtualized guests where the virtual-device backend is outside the same trust boundary as the guest workload.
• Inventory systems for loaded or available virtio Bluetooth support and remove virtual Bluetooth devices from guests that do not require them.
• Apply the fixed kernel from the operating system or appliance vendor and reboot systems so the remediated kernel is active.
• If patching is delayed, disable the virtio_bt module or Bluetooth stack where operationally feasible.
• Monitor kernel logs for Bluetooth, virtio_bt, hci_recv_frame(), and hci_dev_classify_pkt_type warnings, crashes, or oops traces that may indicate malformed packet handling.
• Treat unexpected kernel crashes involving Bluetooth HCI parsing in virtualized systems as potentially security-relevant, especially if the hypervisor, emulator, or device backend is shared or less trusted.
• Track vendor advisories because no exact fixed versions were provided and fixes may be backported under distribution-specific kernel version numbers.