CVE-2026-64456 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
hwrng: virtio: clamp device-reported used.len at copy_data()
random_recv_done() stores the device-reported used.len directly into vi->data_avail. copy_data() then indexes vi->data[] using
vi->data_idx (advanced by previous copy_data() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32 or 64).
A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng.
Concrete impact is inside the guest:
- Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB.
- Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host.
KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000:
BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)
Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened usb9pfs_rx_complete() against unchecked device-reported length in the USB 9p transport.
With the clamp at point of use and array_index_nospec() in place, the same harness boots cleanly: copy_data() returns zero for the bogus report, the device-supplied bytes after data_idx are discarded, and the driver issues a fresh request.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability resides within the Linux kernel's virtio random number generator driver, specifically in how it handles device-reported buffer lengths during data retrieval operations. The flaw manifests in the hwrng subsystem where random_recv_done() function directly assigns the device-reported used.len value to vi->data_avail without any validation against the actual buffer size of vi->data. This buffer is defined as an inline array with a fixed size typically set to SMP_CACHE_BYTES, which is usually 32 or 64 bytes depending on the architecture. The copy_data() function then uses this unvalidated index value along with vi->data_idx to perform a memcpy operation without re-verifying whether these values remain within the bounds of the allocated buffer space.
This memory safety issue creates a potential out-of-bounds read condition that allows malicious or faulty virtio-rng backend implementations to manipulate the used.len field beyond the legitimate buffer boundaries. When such an overflow occurs, the memcpy() operation reads into adjacent kernel heap memory regions, specifically into kmalloc-1k slab allocations that are contiguous to the vi->data array. The KASAN memory safety checker confirms this behavior by detecting a slab-out-of-bounds access at address ffff88800ae0ba20, where the read operation extends beyond the 544-byte allocated region of the kmalloc-1k cache into adjacent heap contents.
The impact of this vulnerability extends to both memory safety and confidential computing threat models. In terms of memory safety, any virtio-rng backend that over-reports used.len causes the driver to read past the end of the inline array into unrelated slab contents, with hwrng_fillfn() being a kernel thread that executes automatically upon device probe without requiring any guest userspace interaction to trigger the out-of-bounds condition. This means the vulnerability can be exploited immediately upon system boot or device initialization, creating a persistent memory safety risk within the guest environment.
From a confidential computing perspective, this bug enables cross-boundary information leakage through the /dev/hwrng interface when combined with malicious hypervisor cooperation. A compromised guest root user can utilize the /dev/hwrng device as a leak channel to extract kernel heap data that was adjacent to the vi->data array in memory. The malicious hypervisor sets a large used.len value, and when the guest root user reads from /dev/hwrng, they receive bytes containing adjacent slab contents that were not intended for exposure. While confidential computing guests such as those using SEV-SNP or TDX typically disable virtio-rng entirely, making this exploitation path narrow, the underlying memory-safety bug still affects all guest systems and remains a significant security concern.
This vulnerability type corresponds to CWE-129, which addresses "Improper Validation of Array Index," and aligns with ATT&CK technique T1059.003 for command and scripting interpreter usage in kernel contexts. The fix implemented follows established patterns used in similar vulnerabilities, such as the one addressed in commit c04db81cd028 for net/9p drivers, by introducing proper bounds checking at the point of use with array_index_nospec() function calls. This approach ensures that when device-reported lengths exceed legitimate buffer boundaries, copy_data() returns zero for invalid reports and issues fresh requests rather than attempting to process corrupted data. The mitigation effectively prevents the out-of-bounds memory access while maintaining the normal operation of the virtio-rng driver functionality.