<?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://cve.radiocsirt.org</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>Mon, 26 Oct 2026 20:31:09 +0000</lastBuildDate>
    <item>
      <title>CVE-2021-47282 — spi: bcm2835: Fix out-of-bounds access with more than 4 slaves</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2021-47282</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;spi: bcm2835: Fix out-of-bounds access with more than 4 slaves&lt;/p&gt;
&lt;p&gt;Commit 571e31fa60b3 (&amp;#34;spi: bcm2835: Cache CS register value for
-&amp;gt;prepare_message()&amp;#34;) limited the number of slaves to 3 at compile-time.
The limitation was necessitated by a statically-sized array prepare_cs[]
in the driver private data which contains a per-slave register value.&lt;/p&gt;
&lt;p&gt;The commit sought to enforce the limitation at run-time by setting the
controller&amp;#39;s num_chipselect to 3:  Slaves with a higher chipselect are
rejected by spi_add_device().&lt;/p&gt;
&lt;p&gt;However the commit neglected that num_chipselect only limits the number
of *native* chipselects.  If GPIO chipselects are specified in the
device tree for more than 3 slaves, num_chipselect is silently raised by
of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to
the statically-sized array prepare_cs[].&lt;/p&gt;
&lt;p&gt;As a bandaid fix which is backportable to stable, raise the number of
allowed slaves to 24 (which &amp;#34;ought to be enough for anybody&amp;#34;), enforce
the limitation on slave -&amp;gt;setup and revert num_chipselect to 3 (which is
the number of native chipselects supported by the controller).
An upcoming for-next commit will allow an arbitrary number of slaves.&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;spi: bcm2835: Fix out-of-bounds access with more than 4 slaves&lt;/p&gt;
&lt;p&gt;Commit 571e31fa60b3 (&amp;#34;spi: bcm2835: Cache CS register value for
-&amp;gt;prepare_message()&amp;#34;) limited the number of slaves to 3 at compile-time.
The limitation was necessitated by a statically-sized array prepare_cs[]
in the driver private data which contains a per-slave register value.&lt;/p&gt;
&lt;p&gt;The commit sought to enforce the limitation at run-time by setting the
controller&amp;#39;s num_chipselect to 3:  Slaves with a higher chipselect are
rejected by spi_add_device().&lt;/p&gt;
&lt;p&gt;However the commit neglected that num_chipselect only limits the number
of *native* chipselects.  If GPIO chipselects are specified in the
device tree for more than 3 slaves, num_chipselect is silently raised by
of_spi_get_gpio_numbers() and the result are out-of-bounds accesses to
the statically-sized array prepare_cs[].&lt;/p&gt;
&lt;p&gt;As a bandaid fix which is backportable to stable, raise the number of
allowed slaves to 24 (which &amp;#34;ought to be enough for anybody&amp;#34;), enforce
the limitation on slave -&amp;gt;setup and revert num_chipselect to 3 (which is
the number of native chipselects supported by the controller).
An upcoming for-next commit will allow an arbitrary number of slaves.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2021-47282</guid>
    </item>
  </channel>
</rss>
