PT-2026-64677 · Linux · Linux
CVE-2026-64456
·
Published
2026-07-25
·
Updated
2026-07-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux