{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.180-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.96-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.4-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux-6.12"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.100-1~deb12u1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003edata_avail.  copy_data() then indexes vi-\u003edata[] using vi-\u003edata_idx (advanced by previous copy_data() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi-\u003edata) (SMP_CACHE_BYTES bytes, typically 32 or 64).  A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi-\u003edata), 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-\u003edata    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-\u003edata.  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.",
  "id": "DEBIAN-CVE-2026-64456",
  "modified": "2026-09-14T16:47:48.843868693Z",
  "published": "2026-07-25T10:17:30.677Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-64456"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-64456"
  ]
}