CVE-2026-64456: hwrng: virtio: clamp device-reported used.len at copy_data()

From: Greg Kroah-Hartman <[email protected]>

Description
===========

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.

The Linux kernel CVE team has assigned CVE-2026-64456 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 2.6.26 with commit f7f510ec195781c857ab76366a3e1c59e1caae42 and fixed in 5.10.261 with commit 3aa3e89cf80721c8d382b4c1a2b70a0449dad4a5
	Issue introduced in 2.6.26 with commit f7f510ec195781c857ab76366a3e1c59e1caae42 and fixed in 5.15.212 with commit 63335e7b638ae70028ae285bb95153874a8bc852
	Issue introduced in 2.6.26 with commit f7f510ec195781c857ab76366a3e1c59e1caae42 and fixed in 6.1.178 with commit 2e788948ff2a13358a303af112497a63201c5739
	Issue introduced in 2.6.26 with commit f7f510ec195781c857ab76366a3e1c59e1caae42 and fixed in 6.6.145 with commit fde19b0d4eeabae042519313c843fe6f27d41e9d
	Issue introduced in 2.6.26 with commit f7f510ec195781c857ab76366a3e1c59e1caae42 and fixed in 6.12.96 with commit 81dd21b5f0c299cc7b5bf84f04a61938559d20e6
	Issue introduced in 2.6.26 with commit f7f510ec195781c857ab76366a3e1c59e1caae42 and fixed in 6.18.39 with commit 285e17c44e3873a73460f294acbd64018ff64385
	Issue introduced in 2.6.26 with commit f7f510ec195781c857ab76366a3e1c59e1caae42 and fixed in 7.1.4 with commit 92d5736a62040ec1cfff23ea57e6599301690ad5
	Issue introduced in 2.6.26 with commit f7f510ec195781c857ab76366a3e1c59e1caae42 and fixed in 7.2-rc1 with commit e3046eeada299f917a8ad883af4434bfb86556b1

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-64456
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/char/hw_random/virtio-rng.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/3aa3e89cf80721c8d382b4c1a2b70a0449dad4a5
	https://git.kernel.org/stable/c/63335e7b638ae70028ae285bb95153874a8bc852
	https://git.kernel.org/stable/c/2e788948ff2a13358a303af112497a63201c5739
	https://git.kernel.org/stable/c/fde19b0d4eeabae042519313c843fe6f27d41e9d
	https://git.kernel.org/stable/c/81dd21b5f0c299cc7b5bf84f04a61938559d20e6
	https://git.kernel.org/stable/c/285e17c44e3873a73460f294acbd64018ff64385
	https://git.kernel.org/stable/c/92d5736a62040ec1cfff23ea57e6599301690ad5
	https://git.kernel.org/stable/c/e3046eeada299f917a8ad883af4434bfb86556b1