<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 05:39:34 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-64456 — hwrng: virtio: clamp device-reported used.len at copy_data()</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-64456</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;hwrng: virtio: clamp device-reported used.len at copy_data()&lt;/p&gt;
&lt;p&gt;random_recv_done() stores the device-reported used.len directly into
vi-&amp;gt;data_avail.  copy_data() then indexes vi-&amp;gt;data[] using
vi-&amp;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-&amp;gt;data) (SMP_CACHE_BYTES bytes, typically 32
or 64).&lt;/p&gt;
&lt;p&gt;A malicious or buggy virtio-rng backend can set used.len beyond
sizeof(vi-&amp;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.&lt;/p&gt;
&lt;p&gt;Concrete impact is inside the guest:&lt;/p&gt;
&lt;p&gt;- Memory-safety / hardening: any virtio-rng backend that
   over-reports used.len causes the driver to read past vi-&amp;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.&lt;/p&gt;
&lt;p&gt;- 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-&amp;gt;data.  In
   practice,…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;hwrng: virtio: clamp device-reported used.len at copy_data()&lt;/p&gt;
&lt;p&gt;random_recv_done() stores the device-reported used.len directly into
vi-&amp;gt;data_avail.  copy_data() then indexes vi-&amp;gt;data[] using
vi-&amp;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-&amp;gt;data) (SMP_CACHE_BYTES bytes, typically 32
or 64).&lt;/p&gt;
&lt;p&gt;A malicious or buggy virtio-rng backend can set used.len beyond
sizeof(vi-&amp;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.&lt;/p&gt;
&lt;p&gt;Concrete impact is inside the guest:&lt;/p&gt;
&lt;p&gt;- Memory-safety / hardening: any virtio-rng backend that
   over-reports used.len causes the driver to read past vi-&amp;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.&lt;/p&gt;
&lt;p&gt;- 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-&amp;gt;data.  In
   practice,…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-64456</guid>
    </item>
  </channel>
</rss>
