CVE-2026-64456: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-64456 Overview

CVE-2026-64456 is an out-of-bounds read vulnerability in the Linux kernel's hwrng virtio driver. The flaw resides in the copy_data() function, which trusts the device-reported used.len value without validating it against the posted buffer size (sizeof(vi->data), typically 32 or 64 bytes). A malicious or buggy virtio-rng backend can report an oversized length, causing memcpy() to read past the inline array into adjacent kmalloc-1k slab memory. The disclosed bytes are then mixed into the guest RNG via hwrng_fillfn() and can be read directly by guest root through /dev/hwrng.

Critical Impact
A malicious hypervisor can use the flaw as a leak channel to exfiltrate guest kernel heap memory through /dev/hwrng, contaminating the guest random number generator on any host.

Affected Products

Linux kernel hwrng virtio driver (drivers/char/hw_random/virtio-rng.c)
Guest virtual machines running the vulnerable virtio-rng driver
Multiple stable kernel branches receiving backported fixes

Discovery Timeline

2026-07-25 - CVE-2026-64456 published to NVD
2026-07-27 - Last updated in NVD database

Technical Details for CVE-2026-64456

Vulnerability Analysis

The vulnerability sits in the virtio_read() and copy_data() code paths of the virtio hardware RNG driver. When the virtio-rng backend completes a request, random_recv_done() stores the device-reported used.len directly into vi->data_avail without validation. Subsequent calls to copy_data() index into vi->data[] using vi->data_idx, which advances across calls, and issue a memcpy() without re-checking either the index or the length against the actual buffer size.

The posted buffer is only SMP_CACHE_BYTES in size, typically 32 or 64 bytes, but the surrounding allocation comes from the kmalloc-1k slab cache. KASAN output from the reporter confirms the out-of-bounds read on a guest with a patched backend reporting used.len = 0x10000, reading 64 bytes at an address 0 bytes past a 544-byte region inside a 1024-byte slab object.

The class of bug matches commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened usb9pfs_rx_complete() against the same pattern of unchecked device-reported length values.

Root Cause

The driver treats the virtio device as trusted and never clamps used.len at point of use. Both data_avail and data_idx are propagated into memcpy() bounds without bounds checking against sizeof(vi->data), and no array_index_nospec() barrier is applied.

Attack Vector

Exploitation requires a malicious or buggy virtio-rng backend, which in practice implies a malicious hypervisor. The trigger fires as soon as the device is probed because hwrng_fillfn() runs as a kernel thread with no guest userspace interaction required. When paired with cooperating guest root, the leaked adjacent slab bytes are returned verbatim through reads on /dev/hwrng, forming a covert channel for guest kernel heap contents. Confidential-compute guests such as SEV-SNP and TDX typically disable virtio-rng, narrowing that specific threat, but the memory-safety defect still contaminates the guest RNG on any host.

No verified public exploit is available. The reproducer described in the commit message uses a modified virtio-rng backend to over-report used.len.

Detection Methods for CVE-2026-64456

Indicators of Compromise

KASAN reports of slab-out-of-bounds reads originating from virtio_read+0x394/0x5d0 in the call stack, invoked from hwrng_fillfn and the hwrng kthread.
Unexpected entropy patterns or repeated identical byte sequences read from /dev/hwrng inside guest VMs.
Guest kernel logs referencing virtio_rng with anomalous data_avail values exceeding SMP_CACHE_BYTES.

Detection Strategies

Enable KASAN in test kernels to surface out-of-bounds reads in the virtio-rng driver during fuzzing of hypervisor backends.
Audit deployed guest kernel versions against the fixed commits (285e17c, 2e78894, 3aa3e89, 63335e7, 81dd21b, 92d5736, e3046ee, fde19b0) to identify unpatched hosts.
Monitor virtio device negotiation for backends that report used.len values inconsistent with the posted buffer size.

Monitoring Recommendations

Collect guest kernel dmesg output centrally and alert on KASAN or BUG: messages referencing virtio_read or hwrng_fillfn.
Track /dev/hwrng read patterns from unexpected userspace processes running as root.
Include kernel version inventory in configuration management to confirm applied stable-tree patches.

How to Mitigate CVE-2026-64456

Immediate Actions Required

Apply the upstream stable kernel patches that clamp used.len at point of use in copy_data() and add an array_index_nospec() barrier.
Prioritize patching guest kernels running under untrusted or multi-tenant hypervisors where the virtio-rng backend is not fully controlled.
Rebuild and redeploy any custom kernel images used in virtualized fleets with the fixed virtio-rng driver.

Patch Information

The fix has been merged across multiple stable branches. Reference the kernel commits: Kernel Patch Commit 285e17c, Kernel Patch Commit 2e78894, Kernel Patch Commit 3aa3e89, Kernel Patch Commit 63335e7, Kernel Patch Commit 81dd21b, Kernel Patch Commit 92d5736, Kernel Patch Commit e3046ee, and Kernel Patch Commit fde19b0. With the clamp and array_index_nospec() in place, copy_data() returns zero for a bogus report and the driver issues a fresh request.

Workarounds

Blacklist the virtio_rng kernel module in guests where hardware RNG is not required (echo 'blacklist virtio_rng' > /etc/modprobe.d/virtio-rng.conf).
Confidential-compute deployments (SEV-SNP, TDX) should continue to disable virtio-rng as part of their trust model.
Restrict read access to /dev/hwrng to trusted system services only, limiting the direct disclosure channel until patches are applied.

bash

# Configuration example: disable virtio-rng module on unpatched guests
echo 'blacklist virtio_rng' | sudo tee /etc/modprobe.d/disable-virtio-rng.conf
sudo update-initramfs -u
sudo reboot

# Verify the module is not loaded
lsmod | grep virtio_rng