CVE-2026-64456

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwrng: virtio: clamp device-reported used.len at copy_data()<br /> <br /> random_recv_done() stores the device-reported used.len directly into<br /> vi-&gt;data_avail. copy_data() then indexes vi-&gt;data[] using<br /> vi-&gt;data_idx (advanced by previous copy_data() calls) and issues a<br /> memcpy() without re-validating either value against the posted<br /> buffer size sizeof(vi-&gt;data) (SMP_CACHE_BYTES bytes, typically 32<br /> or 64).<br /> <br /> A malicious or buggy virtio-rng backend can set used.len beyond<br /> sizeof(vi-&gt;data), steering the memcpy() past the end of the inline<br /> array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes<br /> those bytes into the guest RNG, and guest root can also observe<br /> them directly via /dev/hwrng.<br /> <br /> Concrete impact is inside the guest:<br /> <br /> - Memory-safety / hardening: any virtio-rng backend that<br /> over-reports used.len causes the driver to read past vi-&gt;data<br /> into unrelated slab contents. hwrng_fillfn() is a kernel thread<br /> that runs as soon as the device is probed; no guest userspace<br /> interaction is required to first-trigger the OOB.<br /> <br /> - Cross-boundary leak (confidential-compute threat model): a<br /> malicious hypervisor cooperating with a malicious or compromised<br /> guest root userspace can use /dev/hwrng as a leak channel for<br /> guest-kernel heap data. The host sets a large used.len, guest<br /> root reads /dev/hwrng, and the returned bytes contain guest<br /> kernel slab contents that were adjacent to vi-&gt;data. In<br /> practice, confidential-compute guests (SEV-SNP, TDX) usually<br /> disable virtio-rng entirely, so this path is narrow, but the<br /> fix is still worth carrying because the underlying<br /> memory-safety bug contaminates the guest RNG on any host.<br /> <br /> KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend<br /> has been patched to report used.len = 0x10000:<br /> <br /> BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0<br /> Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52<br /> Call Trace:<br /> __asan_memcpy+0x23/0x60<br /> virtio_read+0x394/0x5d0<br /> hwrng_fillfn+0xb2/0x470<br /> kthread+0x2cc/0x3a0<br /> Allocated by task 1:<br /> probe_common+0xa5/0x660<br /> virtio_dev_probe+0x549/0xbc0<br /> The buggy address belongs to the object at ffff88800ae0b800<br /> which belongs to the cache kmalloc-1k of size 1024<br /> The buggy address is located 0 bytes to the right of<br /> allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)<br /> <br /> Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer<br /> overflow in USB transport layer"), which hardened<br /> usb9pfs_rx_complete() against unchecked device-reported length in<br /> the USB 9p transport.<br /> <br /> With the clamp at point of use and array_index_nospec() in place,<br /> the same harness boots cleanly: copy_data() returns zero for the<br /> bogus report, the device-supplied bytes after data_idx are<br /> discarded, and the driver issues a fresh request.