<?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://db.gcve.eu</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, 03 Nov 2026 11:28:50 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-98566 — drm/imagination: clamp freelist reconstruction requests</title>
      <link>https://db.gcve.eu/vuln/cve-2026-98566</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;drm/imagination: clamp freelist reconstruction requests&lt;/p&gt;
&lt;p&gt;The firmware reconstruction count controls accesses to the request&amp;#39;s
fixed freelist ID array and the copy into the fixed response array.
Neither access currently bounds the count to those protocol arrays.&lt;/p&gt;
&lt;p&gt;Clamp the count to the request capacity, which is shared by the response
layout, and use that count consistently for reconstruction and response
publication. Keep the firmware recovery exchange instead of dropping an
oversized request without a response, as discussed with the firmware
maintainer.&lt;/p&gt;
&lt;p&gt;The issue was found by our static-analysis tool.&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;drm/imagination: clamp freelist reconstruction requests&lt;/p&gt;
&lt;p&gt;The firmware reconstruction count controls accesses to the request&amp;#39;s
fixed freelist ID array and the copy into the fixed response array.
Neither access currently bounds the count to those protocol arrays.&lt;/p&gt;
&lt;p&gt;Clamp the count to the request capacity, which is shared by the response
layout, and use that count consistently for reconstruction and response
publication. Keep the firmware recovery exchange instead of dropping an
oversized request without a response, as discussed with the firmware
maintainer.&lt;/p&gt;
&lt;p&gt;The issue was found by our static-analysis tool.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-98566</guid>
    </item>
  </channel>
</rss>
