<?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>Wed, 07 Oct 2026 15:08:56 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-40974 — powerpc/pseries: Enforce hcall result buffer validity and size</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2024-40974</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;powerpc/pseries: Enforce hcall result buffer validity and size&lt;/p&gt;
&lt;p&gt;plpar_hcall(), plpar_hcall9(), and related functions expect callers to
provide valid result buffers of certain minimum size. Currently this
is communicated only through comments in the code and the compiler has
no idea.&lt;/p&gt;
&lt;p&gt;For example, if I write a bug like this:&lt;/p&gt;
&lt;p&gt;long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE
  plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);&lt;/p&gt;
&lt;p&gt;This compiles with no diagnostics emitted, but likely results in stack
corruption at runtime when plpar_hcall9() stores results past the end
of the array. (To be clear this is a contrived example and I have not
found a real instance yet.)&lt;/p&gt;
&lt;p&gt;To make this class of error less likely, we can use explicitly-sized
array parameters instead of pointers in the declarations for the hcall
APIs. When compiled with -Warray-bounds[1], the code above now
provokes a diagnostic like this:&lt;/p&gt;
&lt;p&gt;error: array argument is too small;
is of size 32, callee requires at least 72 [-Werror,-Warray-bounds]
   60 |                 plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf,
      |                 ^                                   ~~~~~~&lt;/p&gt;
&lt;p&gt;[1] Enabled for LLVM builds but not GCC for now. See commit
    0da6e5fd6c37 (&amp;#34;gcc: disable &amp;#39;-Warray-bounds&amp;#39; for gcc-13 too&amp;#34;) and
    related changes.&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;powerpc/pseries: Enforce hcall result buffer validity and size&lt;/p&gt;
&lt;p&gt;plpar_hcall(), plpar_hcall9(), and related functions expect callers to
provide valid result buffers of certain minimum size. Currently this
is communicated only through comments in the code and the compiler has
no idea.&lt;/p&gt;
&lt;p&gt;For example, if I write a bug like this:&lt;/p&gt;
&lt;p&gt;long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE
  plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);&lt;/p&gt;
&lt;p&gt;This compiles with no diagnostics emitted, but likely results in stack
corruption at runtime when plpar_hcall9() stores results past the end
of the array. (To be clear this is a contrived example and I have not
found a real instance yet.)&lt;/p&gt;
&lt;p&gt;To make this class of error less likely, we can use explicitly-sized
array parameters instead of pointers in the declarations for the hcall
APIs. When compiled with -Warray-bounds[1], the code above now
provokes a diagnostic like this:&lt;/p&gt;
&lt;p&gt;error: array argument is too small;
is of size 32, callee requires at least 72 [-Werror,-Warray-bounds]
   60 |                 plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf,
      |                 ^                                   ~~~~~~&lt;/p&gt;
&lt;p&gt;[1] Enabled for LLVM builds but not GCC for now. See commit
    0da6e5fd6c37 (&amp;#34;gcc: disable &amp;#39;-Warray-bounds&amp;#39; for gcc-13 too&amp;#34;) and
    related changes.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2024-40974</guid>
    </item>
  </channel>
</rss>
