<?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>Thu, 08 Oct 2026 18:39:46 +0000</lastBuildDate>
    <item>
      <title>CVE-2024-31076 — genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2024-31076</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;genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline&lt;/p&gt;
&lt;p&gt;The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
interrupt affinity reconfiguration via procfs. Instead, the change is
deferred until the next instance of the interrupt being triggered on the
original CPU.&lt;/p&gt;
&lt;p&gt;When the interrupt next triggers on the original CPU, the new affinity is
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
but the old vector on the original CPU remains and is not immediately
reclaimed. Instead, apicd-&amp;gt;move_in_progress is flagged, and the reclaiming
process is delayed until the next trigger of the interrupt on the new CPU.&lt;/p&gt;
&lt;p&gt;Upon the subsequent triggering of the interrupt on the new CPU,
irq_complete_move() adds a task to the old CPU&amp;#39;s vector_cleanup list if it
remains online. Subsequently, the timer on the old CPU iterates over its
vector_cleanup list, reclaiming old vectors.&lt;/p&gt;
&lt;p&gt;However, a rare scenario arises if the old CPU is outgoing before the
interrupt triggers again on the new CPU.&lt;/p&gt;
&lt;p&gt;In that case irq_force_complete_move() is not invoked on the outgoing CPU
to reclaim the old apicd-&amp;gt;prev_vector because the interrupt isn&amp;#39;t currently
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
though __vector_schedule_cleanup() is later called on the new CPU, it
doesn&amp;#39;t reclaim apicd-&amp;gt;prev_vector; instead, it simply resets both
apicd-&amp;gt;move_in_progress and apicd-&amp;gt;pr…&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;genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline&lt;/p&gt;
&lt;p&gt;The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
interrupt affinity reconfiguration via procfs. Instead, the change is
deferred until the next instance of the interrupt being triggered on the
original CPU.&lt;/p&gt;
&lt;p&gt;When the interrupt next triggers on the original CPU, the new affinity is
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
but the old vector on the original CPU remains and is not immediately
reclaimed. Instead, apicd-&amp;gt;move_in_progress is flagged, and the reclaiming
process is delayed until the next trigger of the interrupt on the new CPU.&lt;/p&gt;
&lt;p&gt;Upon the subsequent triggering of the interrupt on the new CPU,
irq_complete_move() adds a task to the old CPU&amp;#39;s vector_cleanup list if it
remains online. Subsequently, the timer on the old CPU iterates over its
vector_cleanup list, reclaiming old vectors.&lt;/p&gt;
&lt;p&gt;However, a rare scenario arises if the old CPU is outgoing before the
interrupt triggers again on the new CPU.&lt;/p&gt;
&lt;p&gt;In that case irq_force_complete_move() is not invoked on the outgoing CPU
to reclaim the old apicd-&amp;gt;prev_vector because the interrupt isn&amp;#39;t currently
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
though __vector_schedule_cleanup() is later called on the new CPU, it
doesn&amp;#39;t reclaim apicd-&amp;gt;prev_vector; instead, it simply resets both
apicd-&amp;gt;move_in_progress and apicd-&amp;gt;pr…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2024-31076</guid>
    </item>
  </channel>
</rss>
