<?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, 06 Oct 2026 00:14:17 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-52977 — futex: Prevent lockup in requeue-PI during signal/ timeout wakeup</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-52977</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;futex: Prevent lockup in requeue-PI during signal/ timeout wakeup&lt;/p&gt;
&lt;p&gt;During wait-requeue-pi (task A) and requeue-PI (task B) the following
race can happen:&lt;/p&gt;
&lt;p&gt;Task A                             Task B
  futex_wait_requeue_pi()
    futex_setup_timer()
    futex_do_wait()
                                   futex_requeue()
                                        CLASS(hb, hb1)(&amp;amp;key1);
                                        CLASS(hb, hb2)(&amp;amp;key2);
        *timeout*
    futex_requeue_pi_wakeup_sync()
        requeue_state = Q_REQUEUE_PI_IGNORE&lt;/p&gt;
&lt;p&gt;*blocks on hb-&amp;gt;lock*&lt;/p&gt;
&lt;p&gt;futex_proxy_trylock_atomic()
                                          futex_requeue_pi_prepare()
                                            Q_REQUEUE_PI_IGNORE =&amp;gt; -EAGAIN
                                        double_unlock_hb(hb1, hb2)
                                         *retry*&lt;/p&gt;
&lt;p&gt;Task B acquires both hb locks and attempts to acquire the PI-lock of the
top most waiter (task B). Task A is leaving early due to a signal/
timeout and started removing itself from the queue. It updates its
requeue_state but can not remove it from the list because this requires
the hb lock which is owned by task B.&lt;/p&gt;
&lt;p&gt;Usually task A is able to swoop the lock after task B unlocked it.
However if task B is of higher priority then task A may not be able to
wake up in time and acquire the lock before task B gets it again.
Espec…&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;futex: Prevent lockup in requeue-PI during signal/ timeout wakeup&lt;/p&gt;
&lt;p&gt;During wait-requeue-pi (task A) and requeue-PI (task B) the following
race can happen:&lt;/p&gt;
&lt;p&gt;Task A                             Task B
  futex_wait_requeue_pi()
    futex_setup_timer()
    futex_do_wait()
                                   futex_requeue()
                                        CLASS(hb, hb1)(&amp;amp;key1);
                                        CLASS(hb, hb2)(&amp;amp;key2);
        *timeout*
    futex_requeue_pi_wakeup_sync()
        requeue_state = Q_REQUEUE_PI_IGNORE&lt;/p&gt;
&lt;p&gt;*blocks on hb-&amp;gt;lock*&lt;/p&gt;
&lt;p&gt;futex_proxy_trylock_atomic()
                                          futex_requeue_pi_prepare()
                                            Q_REQUEUE_PI_IGNORE =&amp;gt; -EAGAIN
                                        double_unlock_hb(hb1, hb2)
                                         *retry*&lt;/p&gt;
&lt;p&gt;Task B acquires both hb locks and attempts to acquire the PI-lock of the
top most waiter (task B). Task A is leaving early due to a signal/
timeout and started removing itself from the queue. It updates its
requeue_state but can not remove it from the list because this requires
the hb lock which is owned by task B.&lt;/p&gt;
&lt;p&gt;Usually task A is able to swoop the lock after task B unlocked it.
However if task B is of higher priority then task A may not be able to
wake up in time and acquire the lock before task B gets it again.
Espec…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-52977</guid>
    </item>
  </channel>
</rss>
