<?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 08:43:29 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-89856 — scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-89856</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;scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation&lt;/p&gt;
&lt;p&gt;ha-&amp;gt;msix_count is u16, but ha-&amp;gt;max_req_queues, ha-&amp;gt;max_rsp_queues and
ha-&amp;gt;max_qpairs are u8. Deriving the queue count as
&amp;#34;ha-&amp;gt;max_req_queues = ha-&amp;gt;msix_count - 1&amp;#34; therefore truncates: a board
(or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X
vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X
count of 1 zeroes it as well, and in target mode the subsequent
&amp;#34;ha-&amp;gt;max_req_queues--&amp;#34; then underflows 0 to 255.&lt;/p&gt;
&lt;p&gt;When the count is 0, qla2x00_alloc_queues() calls
kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is
not NULL, so the allocation check passes and the following
&amp;#34;ha-&amp;gt;req_q_map[0] = req&amp;#34; dereferences ZERO_SIZE_PTR, corrupting memory
or crashing the kernel.&lt;/p&gt;
&lt;p&gt;Add qla_calc_queue_count() to clamp the derived value into
[1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and
use it at all three derivation sites (qla25xx_iospace_config(),
qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the
target-mode decrement so it cannot reintroduce a zero (which would in
turn underflow max_qpairs).&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;scsi: qla2xxx: Clamp MSI-X derived queue counts to avoid truncation&lt;/p&gt;
&lt;p&gt;ha-&amp;gt;msix_count is u16, but ha-&amp;gt;max_req_queues, ha-&amp;gt;max_rsp_queues and
ha-&amp;gt;max_qpairs are u8. Deriving the queue count as
&amp;#34;ha-&amp;gt;max_req_queues = ha-&amp;gt;msix_count - 1&amp;#34; therefore truncates: a board
(or a misconfigured/malicious hot-plugged device) advertising 257 MSI-X
vectors yields msix_count - 1 == 256, which truncates to 0. An MSI-X
count of 1 zeroes it as well, and in target mode the subsequent
&amp;#34;ha-&amp;gt;max_req_queues--&amp;#34; then underflows 0 to 255.&lt;/p&gt;
&lt;p&gt;When the count is 0, qla2x00_alloc_queues() calls
kzalloc_objs(struct req_que *, 0), which returns ZERO_SIZE_PTR. That is
not NULL, so the allocation check passes and the following
&amp;#34;ha-&amp;gt;req_q_map[0] = req&amp;#34; dereferences ZERO_SIZE_PTR, corrupting memory
or crashing the kernel.&lt;/p&gt;
&lt;p&gt;Add qla_calc_queue_count() to clamp the derived value into
[1, QLA_MAX_QUEUES - 1] so it always fits in u8 and is never zero, and
use it at all three derivation sites (qla25xx_iospace_config(),
qla83xx_iospace_config() and qla24xx_enable_msix()). Also guard the
target-mode decrement so it cannot reintroduce a zero (which would in
turn underflow max_qpairs).&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-89856</guid>
    </item>
  </channel>
</rss>
