<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T08:23:29.406849+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-64456</id>
    <title>CVE-2026-64456 — hwrng: virtio: clamp device-reported used.len at copy_data()</title>
    <updated>2026-09-30T08:23:30.799769+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>hwrng: virtio: clamp device-reported used.len at copy_data()</p>
<p>random_recv_done() stores the device-reported used.len directly into
vi-&gt;data_avail.  copy_data() then indexes vi-&gt;data[] using
vi-&gt;data_idx (advanced by previous copy_data() calls) and issues a
memcpy() without re-validating either value against the posted
buffer size sizeof(vi-&gt;data) (SMP_CACHE_BYTES bytes, typically 32
or 64).</p>
<p>A malicious or buggy virtio-rng backend can set used.len beyond
sizeof(vi-&gt;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.</p>
<p>Concrete impact is inside the guest:</p>
<p>- Memory-safety / hardening: any virtio-rng backend that
   over-reports used.len causes the driver to read past vi-&gt;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.</p>
<p>- 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-&gt;data.  In
   practice,…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-64456"/>
  </entry>
</feed>
