<?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 21:45:54 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-15375</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-15375</link>
      <description>bdu:2025-15375</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-15375</guid>
    </item>
    <item>
      <title>EUVD-2026-344444</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-344444</link>
      <description>EUVD-2026-344444</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-344444</guid>
    </item>
    <item>
      <title>fkie_cve-2021-47282</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2021-47282</link>
      <description>&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;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/fkie_cve-2021-47282</guid>
    </item>
    <item>
      <title>GHSA-3wh6-h4gj-wjr7</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-3wh6-h4gj-wjr7</link>
      <description>&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;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/ghsa-3wh6-h4gj-wjr7</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2021-47282</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47282</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-gcp-5.4, Ubuntu:18.04:LTS: linux-hwe-5.4, Ubuntu:18.04:LTS: linux-oracle-5.4, Ubuntu:18.04:LTS: linux-raspi-5.4, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure and 79 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: spi: bcm2835: Fix out-of-bounds access with more than 4 slaves 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. 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(). 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[]. 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; Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-gcp-5.4, Ubuntu:18.04:LTS: linux-hwe-5.4, Ubuntu:18.04:LTS: linux-oracle-5.4, Ubuntu:18.04:LTS: linux-raspi-5.4, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure and 79 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: spi: bcm2835: Fix out-of-bounds access with more than 4 slaves 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. 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(). 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[]. 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/ubuntu-cve-2021-47282</guid>
    </item>
  </channel>
</rss>
