<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-03T20:42:14.435003+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2026-52977</id>
    <title>BELL-CVE-2026-52977</title>
    <updated>2026-10-03T20:42:15.350229+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2026-52977"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0862</id>
    <title>certfr-2026-avi-0862 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Certaines d'entre elles permettent à…</title>
    <updated>2026-10-03T20:42:15.350312+00:00</updated>
    <content>certfr-2026-avi-0862</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2026-avi-0862"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-355967</id>
    <title>EUVD-2026-355967</title>
    <updated>2026-10-03T20:42:15.350335+00:00</updated>
    <content>EUVD-2026-355967</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-355967"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-52977</id>
    <title>fkie_cve-2026-52977</title>
    <updated>2026-10-03T20:42:15.350349+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>futex: Prevent lockup in requeue-PI during signal/ timeout wakeup</p>
<p>During wait-requeue-pi (task A) and requeue-PI (task B) the following
race can happen:</p>
<p>Task A                             Task B
  futex_wait_requeue_pi()
    futex_setup_timer()
    futex_do_wait()
                                   futex_requeue()
                                        CLASS(hb, hb1)(&amp;key1);
                                        CLASS(hb, hb2)(&amp;key2);
        *timeout*
    futex_requeue_pi_wakeup_sync()
        requeue_state = Q_REQUEUE_PI_IGNORE</p>
<p>*blocks on hb-&gt;lock*</p>
<p>futex_proxy_trylock_atomic()
                                          futex_requeue_pi_prepare()
                                            Q_REQUEUE_PI_IGNORE =&gt; -EAGAIN
                                        double_unlock_hb(hb1, hb2)
                                         *retry*</p>
<p>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.</p>
<p>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…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-52977"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-f389-gw66-p7gf</id>
    <title>GHSA-f389-gw66-p7gf</title>
    <updated>2026-10-03T20:42:15.350396+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>futex: Prevent lockup in requeue-PI during signal/ timeout wakeup</p>
<p>During wait-requeue-pi (task A) and requeue-PI (task B) the following
race can happen:</p>
<p>Task A                             Task B
  futex_wait_requeue_pi()
    futex_setup_timer()
    futex_do_wait()
                                   futex_requeue()
                                        CLASS(hb, hb1)(&amp;key1);
                                        CLASS(hb, hb2)(&amp;key2);
        *timeout*
    futex_requeue_pi_wakeup_sync()
        requeue_state = Q_REQUEUE_PI_IGNORE</p>
<p>*blocks on hb-&gt;lock*</p>
<p>futex_proxy_trylock_atomic()
                                          futex_requeue_pi_prepare()
                                            Q_REQUEUE_PI_IGNORE =&gt; -EAGAIN
                                        double_unlock_hb(hb1, hb2)
                                         *retry*</p>
<p>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.</p>
<p>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…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-f389-gw66-p7gf"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2026-52977</id>
    <title>msrc_CVE-2026-52977 — futex: Prevent lockup in requeue-PI during signal/ timeout wakeup</title>
    <updated>2026-10-03T20:42:15.350430+00:00</updated>
    <content>msrc_CVE-2026-52977</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2026-52977"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-1</id>
    <title>openSUSE-SU-2026:21910-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-03T20:42:15.350449+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2026:23477-1</id>
    <title>SUSE-SU-2026:23477-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-03T20:42:15.350932+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2026:23477-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-52977</id>
    <title>UBUNTU-CVE-2026-52977</title>
    <updated>2026-10-03T20:42:15.351308+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 200 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: futex: Prevent lockup in requeue-PI during signal/ timeout wakeup During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen:      Task A                             Task B   futex_wait_requeue_pi()     futex_setup_timer()     futex_do_wait()                                    futex_requeue()                                         CLASS(hb, hb1)(&amp;key1);                                         CLASS(hb, hb2)(&amp;key2);         *timeout*     futex_requeue_pi_wakeup_sync()         requeue_state = Q_REQUEUE_PI_IGNORE     *blocks on hb-&gt;lock*                                         futex_proxy_trylock_atomic()                                           futex_requeue_pi_prepare()                                             Q_REQUEUE_PI_IGNORE =&gt; -EAGAIN                                         double_unlock_hb(hb1, hb2)                                          *retry* 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. 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. Especially o…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-52977"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2077</id>
    <title>WID-SEC-W-2026-2077 — Linux Kernel: Mehrere Schwachstellen</title>
    <updated>2026-10-03T20:42:15.351552+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein entfernter Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um Sicherheitsvorkehrungen zu umgehen, einen Denial-of-Service-Zustand herbeizuführen und weitere, nicht näher spezifizierte Auswirkungen zu erzielen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2077"/>
  </entry>
</feed>
