CVE-2026-64456

What it actually does

This flaw is an out-of-bounds read in the Linux kernel virtio-rng hardware random number generator driver. The driver trusts a length value reported by the virtio-rng backend and later uses it during memcpy() without rechecking that the length is within the size of the posted inline buffer. A malicious or faulty virtio-rng backend can over-report the number of bytes returned, causing the guest kernel to read past the virtio-rng buffer into adjacent kmalloc slab memory. Those unintended bytes may be mixed into the guest random-number pool and, where /dev/hwrng is accessible to privileged guest users, may be directly observed. The primary consequence is disclosure of guest kernel heap contents and contamination of RNG input; the bug may also trigger kernel memory-safety diagnostics or instability depending on configuration.

Why it matters to the business

Organizations running Linux guests with virtio-rng enabled on untrusted, compromised, or multi-tenant virtualization infrastructure may face leakage of sensitive guest kernel memory and reduced trust in guest randomness. The risk is most relevant where the hypervisor or virtio device backend is outside the same trust boundary as the guest, including confidential-computing scenarios, although many confidential-computing deployments disable virtio-rng by design. The vulnerability is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, it matters for high-assurance virtualized workloads and environments with strict host/guest isolation requirements.

How an attack unfolds

An attacker needs control over, or the ability to influence, the virtio-rng backend presented to a Linux guest. The malicious backend completes a virtio-rng request with a used.len value larger than the actual driver buffer size. The guest virtio-rng driver stores that device-reported length and later copies data based on it without clamping the length to the posted buffer. This causes the kernel thread servicing the hardware RNG to read beyond the intended buffer into neighboring kernel heap memory. The leaked bytes can be mixed into the guest RNG pool automatically when the device is probed. If the attacker also has privileged access inside the guest, they may read /dev/hwrng and retrieve bytes that include adjacent guest kernel slab contents. Exploitation is therefore most plausible through a malicious or compromised host, hypervisor, emulator, or device backend rather than through a remote network request to the guest.

How to fix it

Upgrade to a Linux kernel build that includes the virtio-rng fix which clamps the device-reported used.len at the point of use and applies bounds-safe indexing before copying data. Where exact vendor package versions are not available, use the latest security update from the Linux distribution, kernel vendor, cloud image provider, or appliance vendor for all affected kernel branches. As a mitigation, disable virtio-rng for guests that do not require it, especially where the hypervisor or device backend is outside the guest's trust boundary. For confidential-computing workloads, verify whether virtio-rng is disabled by policy and prefer trusted in-guest or platform-approved entropy sources. Restrict access to /dev/hwrng to privileged users only, although this does not prevent the kernel-side out-of-bounds read from occurring.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version includes the vendor fix for the virtio-rng used.len bounds check. Check whether the virtio-rng module or driver is present and active, for example by reviewing loaded modules, kernel device listings, and dmesg output for virtio_rng or hwrng registration. Validate exposure by confirming whether guests are configured with a virtio-rng device and whether /dev/hwrng exists. In test environments only, a controlled malicious or instrumented virtio-rng backend should no longer trigger KASAN slab-out-of-bounds reports, and bogus oversized completions should be discarded or cause a fresh request rather than copying beyond the internal buffer.

Typical attack path

1. Gain control of or compromise the virtualization layer, hypervisor, emulator, or virtio-rng backend serving a Linux guest.
2. Expose or keep enabled a virtio-rng device to the guest.
3. Return a crafted virtio-rng completion where the device-reported used.len exceeds the size of the guest driver's internal data buffer.
4. Allow the guest kernel hwrng worker to process the completion and call the vulnerable copy path.
5. Cause the guest kernel to read beyond the virtio-rng buffer into adjacent kernel heap memory.
6. Optionally use privileged guest access to read /dev/hwrng and observe leaked bytes, or rely on the unintended bytes being mixed into the guest RNG pool.

How to detect it

Look for signs that the virtio-rng driver experienced out-of-bounds reads or abnormal hardware RNG behavior. Useful sources include kernel logs, dmesg, system journal entries, hypervisor or emulator logs, crash dumps, KASAN reports, and guest audit logs showing unusual privileged reads from /dev/hwrng. In hardened or test kernels, exploitation may produce KASAN messages naming virtio_read, hwrng_fillfn, __asan_memcpy, slab-out-of-bounds, or kmalloc-1k. In production kernels without sanitizers, there may be no direct log evidence; focus on whether virtio-rng was enabled, whether the host or device backend was compromised, whether the guest consumed /dev/hwrng, and whether there were unexplained kernel crashes, RNG anomalies, or hwrng worker faults. Because exploitation requires a malicious or buggy backend, correlate guest indicators with hypervisor changes, emulator modifications, suspicious QEMU or vhost activity, and administrative events that altered virtual device configuration.

• BUG: KASAN: slab-out-of-bounds in virtio_read
• slab-out-of-bounds in virtio_read
• Read of size 64 at addr
• task hwrng
• hwrng_fillfn
• __asan_memcpy
• virtio_read+
• probe_common+
• virtio_dev_probe+
• kmalloc-1k
• /dev/hwrng
• virtio_rng
• virtio-rng
• hwrng/
• random_recv_done
• copy_data()
• used.len = 0x10000

What your security team should do

• Prioritize patching Linux guests that run on untrusted, shared, third-party, or less trusted virtualization infrastructure and have virtio-rng enabled.
• Inventory virtual machines and images for virtio-rng exposure, including the presence of /dev/hwrng and virtio_rng driver registration.
• Apply vendor kernel updates as they become available; where patch timing is constrained, disable virtio-rng for sensitive workloads as an interim mitigation.
• Review confidential-computing guest configurations to ensure entropy sources align with the intended host/guest trust model.
• Monitor kernel logs for memory-safety warnings involving virtio_read, hwrng_fillfn, KASAN, or slab-out-of-bounds conditions.
• Treat evidence of this bug being triggered as a potential host or virtio backend trust-boundary incident, not merely as a guest-local application issue.