Intel

CVE-2026-64456

Linux kernel (GCP) vulnerabilities

highEPSS 0.1 %

Beschreibung

Im Linux-Kernel wurde folgende Schwachstelle behoben:

hwrng: virtio: Begrenzung der von Geräten gemeldeten used.len bei copy_data()

Die Funktion random_recv_done() speichert die vom Gerät gemeldete used.len direkt in vi->data_avail. Die Funktion copy_data() verwendet dann den Index vi->data[] basierend auf vi->data_idx (fortgeschritten durch vorherige Aufrufe von copy_data()) und führt eine memcpy()-Operation ohne erneute Überprüfung beider Werte gegen die angegebene Puffergröße sizeof(vi->data) (SMP_CACHE_BYTES Bytes, typischerweise 32 oder 64) aus.

Ein böswilliger oder fehlerhafter virtio-rng-Backend kann used.len über sizeof(vi->data) setzen und so die memcpy()-Operation über das Ende des Inline-Arrays hinaus in benachbarte kmalloc-1k-Slab-Bytes lenken. Die Funktion hwrng_fillfn() mischt diese Bytes in den Gast-RNG ein, und der Gastroot kann sie auch direkt über /dev/hwrng beobachten.

Konkrete Auswirkungen innerhalb des Gasts:

  • Memory-safety / Hardening: Jedes virtio-rng-Backend, das used.len überschreibt, veranlasst den Treiber, außerhalb von vi->data in den Inhalt anderer Slabs zu lesen. hwrng_fillfn() ist ein Kernelthread, der sofort ausgeführt wird, sobald das Gerät geprüft wurde; keine Interaktion mit dem Gastuserspace ist erforderlich, um die OOB-Auslösung auszulösen.

  • Cross-boundary Leak (confidential-compute Bedrohungsmodell): Ein böswilliger Hypervisor in Zusammenarbeit mit einem böswilligen oder kompromittierten Gastroot-userspace kann /dev/hwrng als Leckkanal für Daten des Gastkernel-Heaps verwenden. Der Host setzt ein großes used.len, der Gastroot liest /dev/hwrng und die zurückgegebenen Bytes enthalten den Inhalt von Gastkernel-Slabs, die benachbart zu vi->data sind. Praktisch gesehen deaktivieren Gäste im confidential-compute-Modus (SEV-SNP, TDX) virtio-rng vollständig, wodurch dieser Pfad eng ist, aber das Fix ist dennoch sinnvoll, da der zugrunde liegende Memory-safety-Fehler den Gast-RNG auf jedem Host kontaminiert.

KASAN bestätigt die OOB bei einem 7.1-rc4-Gast, dessen virtio-rng-Backend gepatcht wurde, um used.len = 0x10000 zu melden:

BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Lesen von Größe 64 bei Adresse ffff88800ae0ba20 durch Aufgabe hwrng/52 Aufrufverfolgung: __asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Zugeteilt von Aufgabe 1: probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 Die fehlerhafte Adresse gehört zum Objekt bei ffff88800ae0b800, das zur Cache kmalloc-1k der Größe 1024 gehört Die fehlerhafte Adresse befindet sich 0 Bytes rechts des zugewiesenen 544-Byte-Bereichs [ffff88800ae0b800, ffff88800ae0ba20)

Derselbe Fehlerklasse wie der Commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), der usb9pfs_rx_complete() gegen unkontrollierte von Geräten gemeldete Länge im USB 9p-Transport abgesichert hat.

Mit der Begrenzung am Punkt der Verwendung und array_index_nospec() an Ort und Stelle, startet dasselbe Harness sauber: copy_data() gibt null für den falschen Bericht zurück, die vom Gerät bereitgestellten Bytes nach data_idx werden verworfen und der Treiber stellt eine frische Anfrage aus.

Quelle: UBUNTU_USNUBUNTU_USNUBUNTU_USNBSIBSI_CSAFMSRCNVDCVELISTV5

Metriken

Severity
high
Priority-Score
231.31
KEV-Status
—
Exploit-Reife
kein öffentlicher PoC bekannt
XIEM Effective CVSS
8.4
Quelle: nvd-v3
CVSS v3
8.4
CVSS v4
—
EPSS-Perzentil
4.3 %
Niedrig — CVE gehört zu den unteren 10 % der heute bewerteten CVEs.
EPSS-Score
0.1 %
Niedrig — Modell schätzt < 1 % Ausnutzungs-Wahrscheinlichkeit.
Veröffentlicht
2026-09-07 09:05 UTC
CWE
—

Re-Analyse & Statuswechsel

Chronologie der NVD-Audit-Events für diese CVE — Reanalyses, CVSS-Updates, CPE-Diffs.

  1. CVE Modified2026-08-17 05:17 UTC· 416baaa9-dc9f-4396-8d5f-8c081fb06d67
    • Affected: Linux, Linux → Linux, Linux
  2. New CVE Received2026-07-25 10:17 UTC· 416baaa9-dc9f-4396-8d5f-8c081fb06d67
    • Affected: Linux, Linux
    • 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.
    • Reference: https://git.kernel.org/stable/c/285e17c44e3873a73460f294acbd64018ff64385
    • Reference: https://git.kernel.org/stable/c/2e788948ff2a13358a303af112497a63201c5739

Betroffene Betriebssysteme

  • linux

    redhat / enterprise_linux10.0

  • linux

    redhat / enterprise_linux7.0

  • linux

    redhat / enterprise_linux8.0

  • linux

    redhat / enterprise_linux9.0

  • linux

    ubuntu / linux-aws-6.8jammy

  • linux

    ubuntu / linux-azureresolute

  • linux

    ubuntu / linux-azuretrusty

  • linux

    ubuntu / linux-azurexenial

  • linux

    ubuntu / linux-azure-4.15bionic

  • linux

    ubuntu / linux-azure-5.4bionic

  • linux

    ubuntu / linux-azure-fdenoble

  • linux

    ubuntu / linux-azure-fderesolute

  • linux

    ubuntu / linux-azure-fde-6.8jammy

  • linux

    ubuntu / linux-azure-fipsbionic

  • linux

    ubuntu / linux-azure-fipsfocal

  • linux

    ubuntu / linux-azure-fipsnoble

  • linux

    ubuntu / linux-fipsjammy

  • linux

    ubuntu / linux-gcp-7.0noble

  • linux

    ubuntu / linux-gkejammy

  • linux

    ubuntu / linux-nvidia-tegranoble

  • linux

    ubuntu / linux-raspinoble

  • linux

    ubuntu / linux-raspi-realtimenoble

  • linux

    linux / linux_kernel2.6.12

  • linux

    linux / linux_kernel2.6.15

Quellen & Referenzen

Verknüpfte CVEs

1392 weitere CVEs anzeigen
IDCVE-2026-64456
Linux kernel (GCP) vulnerabilities — CVE-2026-64456 | NEOSEC Intel