<?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>Fri, 02 Oct 2026 18:53:42 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-11062</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-11062</link>
      <description>bdu:2026-11062</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-11062</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-71079</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-71079</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2025-71079</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0166 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0166</link>
      <description>certfr-2026-avi-0166</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0166</guid>
    </item>
    <item>
      <title>EUVD-2026-364612</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-364612</link>
      <description>EUVD-2026-364612</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-364612</guid>
    </item>
    <item>
      <title>fkie_cve-2025-71079</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-71079</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write&lt;/p&gt;
&lt;p&gt;A deadlock can occur between nfc_unregister_device() and rfkill_fop_write()
due to lock ordering inversion between device_lock and rfkill_global_mutex.&lt;/p&gt;
&lt;p&gt;The problematic lock order is:&lt;/p&gt;
&lt;p&gt;Thread A (rfkill_fop_write):
  rfkill_fop_write()
    mutex_lock(&amp;amp;rfkill_global_mutex)
      rfkill_set_block()
        nfc_rfkill_set_block()
          nfc_dev_down()
            device_lock(&amp;amp;dev-&amp;gt;dev)    &amp;lt;- waits for device_lock&lt;/p&gt;
&lt;p&gt;Thread B (nfc_unregister_device):
  nfc_unregister_device()
    device_lock(&amp;amp;dev-&amp;gt;dev)
      rfkill_unregister()
        mutex_lock(&amp;amp;rfkill_global_mutex)  &amp;lt;- waits for rfkill_global_mutex&lt;/p&gt;
&lt;p&gt;This creates a classic ABBA deadlock scenario.&lt;/p&gt;
&lt;p&gt;Fix this by moving rfkill_unregister() and rfkill_destroy() outside the
device_lock critical section. Store the rfkill pointer in a local variable
before releasing the lock, then call rfkill_unregister() after releasing
device_lock.&lt;/p&gt;
&lt;p&gt;This change is safe because rfkill_fop_write() holds rfkill_global_mutex
while calling the rfkill callbacks, and rfkill_unregister() also acquires
rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will
wait for any ongoing callback to complete before proceeding, and
device_del() is only called after rfkill_unregister() returns, preventing
any use-after-free.&lt;/p&gt;
&lt;p&gt;The similar lock ordering in nfc_register_device() (device_lock -&amp;gt;
rfkill_global_mutex v…&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;net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write&lt;/p&gt;
&lt;p&gt;A deadlock can occur between nfc_unregister_device() and rfkill_fop_write()
due to lock ordering inversion between device_lock and rfkill_global_mutex.&lt;/p&gt;
&lt;p&gt;The problematic lock order is:&lt;/p&gt;
&lt;p&gt;Thread A (rfkill_fop_write):
  rfkill_fop_write()
    mutex_lock(&amp;amp;rfkill_global_mutex)
      rfkill_set_block()
        nfc_rfkill_set_block()
          nfc_dev_down()
            device_lock(&amp;amp;dev-&amp;gt;dev)    &amp;lt;- waits for device_lock&lt;/p&gt;
&lt;p&gt;Thread B (nfc_unregister_device):
  nfc_unregister_device()
    device_lock(&amp;amp;dev-&amp;gt;dev)
      rfkill_unregister()
        mutex_lock(&amp;amp;rfkill_global_mutex)  &amp;lt;- waits for rfkill_global_mutex&lt;/p&gt;
&lt;p&gt;This creates a classic ABBA deadlock scenario.&lt;/p&gt;
&lt;p&gt;Fix this by moving rfkill_unregister() and rfkill_destroy() outside the
device_lock critical section. Store the rfkill pointer in a local variable
before releasing the lock, then call rfkill_unregister() after releasing
device_lock.&lt;/p&gt;
&lt;p&gt;This change is safe because rfkill_fop_write() holds rfkill_global_mutex
while calling the rfkill callbacks, and rfkill_unregister() also acquires
rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will
wait for any ongoing callback to complete before proceeding, and
device_del() is only called after rfkill_unregister() returns, preventing
any use-after-free.&lt;/p&gt;
&lt;p&gt;The similar lock ordering in nfc_register_device() (device_lock -&amp;gt;
rfkill_global_mutex v…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-71079</guid>
    </item>
    <item>
      <title>GHSA-q63x-gg9g-q34f</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-q63x-gg9g-q34f</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write&lt;/p&gt;
&lt;p&gt;A deadlock can occur between nfc_unregister_device() and rfkill_fop_write()
due to lock ordering inversion between device_lock and rfkill_global_mutex.&lt;/p&gt;
&lt;p&gt;The problematic lock order is:&lt;/p&gt;
&lt;p&gt;Thread A (rfkill_fop_write):
  rfkill_fop_write()
    mutex_lock(&amp;amp;rfkill_global_mutex)
      rfkill_set_block()
        nfc_rfkill_set_block()
          nfc_dev_down()
            device_lock(&amp;amp;dev-&amp;gt;dev)    &amp;lt;- waits for device_lock&lt;/p&gt;
&lt;p&gt;Thread B (nfc_unregister_device):
  nfc_unregister_device()
    device_lock(&amp;amp;dev-&amp;gt;dev)
      rfkill_unregister()
        mutex_lock(&amp;amp;rfkill_global_mutex)  &amp;lt;- waits for rfkill_global_mutex&lt;/p&gt;
&lt;p&gt;This creates a classic ABBA deadlock scenario.&lt;/p&gt;
&lt;p&gt;Fix this by moving rfkill_unregister() and rfkill_destroy() outside the
device_lock critical section. Store the rfkill pointer in a local variable
before releasing the lock, then call rfkill_unregister() after releasing
device_lock.&lt;/p&gt;
&lt;p&gt;This change is safe because rfkill_fop_write() holds rfkill_global_mutex
while calling the rfkill callbacks, and rfkill_unregister() also acquires
rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will
wait for any ongoing callback to complete before proceeding, and
device_del() is only called after rfkill_unregister() returns, preventing
any use-after-free.&lt;/p&gt;
&lt;p&gt;The similar lock ordering in nfc_register_device() (device_lock -&amp;gt;
rfkill_global_mutex v…&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;net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write&lt;/p&gt;
&lt;p&gt;A deadlock can occur between nfc_unregister_device() and rfkill_fop_write()
due to lock ordering inversion between device_lock and rfkill_global_mutex.&lt;/p&gt;
&lt;p&gt;The problematic lock order is:&lt;/p&gt;
&lt;p&gt;Thread A (rfkill_fop_write):
  rfkill_fop_write()
    mutex_lock(&amp;amp;rfkill_global_mutex)
      rfkill_set_block()
        nfc_rfkill_set_block()
          nfc_dev_down()
            device_lock(&amp;amp;dev-&amp;gt;dev)    &amp;lt;- waits for device_lock&lt;/p&gt;
&lt;p&gt;Thread B (nfc_unregister_device):
  nfc_unregister_device()
    device_lock(&amp;amp;dev-&amp;gt;dev)
      rfkill_unregister()
        mutex_lock(&amp;amp;rfkill_global_mutex)  &amp;lt;- waits for rfkill_global_mutex&lt;/p&gt;
&lt;p&gt;This creates a classic ABBA deadlock scenario.&lt;/p&gt;
&lt;p&gt;Fix this by moving rfkill_unregister() and rfkill_destroy() outside the
device_lock critical section. Store the rfkill pointer in a local variable
before releasing the lock, then call rfkill_unregister() after releasing
device_lock.&lt;/p&gt;
&lt;p&gt;This change is safe because rfkill_fop_write() holds rfkill_global_mutex
while calling the rfkill callbacks, and rfkill_unregister() also acquires
rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will
wait for any ongoing callback to complete before proceeding, and
device_del() is only called after rfkill_unregister() returns, preventing
any use-after-free.&lt;/p&gt;
&lt;p&gt;The similar lock ordering in nfc_register_device() (device_lock -&amp;gt;
rfkill_global_mutex v…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-q63x-gg9g-q34f</guid>
    </item>
    <item>
      <title>ICSA-26-209-04 — Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-26-209-04</link>
      <description>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-26-209-04</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-71079 — net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-71079</link>
      <description>msrc_CVE-2025-71079</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-71079</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:20287-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20287-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:20287-1</guid>
    </item>
    <item>
      <title>SSA-019113 — SSA-019113: Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP V3.1.6</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-019113</link>
      <description>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-019113</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:0587-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:0587-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:0587-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-71079</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-71079</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 222 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write A deadlock can occur between nfc_unregister_device() and rfkill_fop_write() due to lock ordering inversion between device_lock and rfkill_global_mutex. The problematic lock order is: Thread A (rfkill_fop_write):   rfkill_fop_write()     mutex_lock(&amp;amp;rfkill_global_mutex)       rfkill_set_block()         nfc_rfkill_set_block()           nfc_dev_down()             device_lock(&amp;amp;dev-&amp;gt;dev)    &amp;lt;- waits for device_lock Thread B (nfc_unregister_device):   nfc_unregister_device()     device_lock(&amp;amp;dev-&amp;gt;dev)       rfkill_unregister()         mutex_lock(&amp;amp;rfkill_global_mutex)  &amp;lt;- waits for rfkill_global_mutex This creates a classic ABBA deadlock scenario. Fix this by moving rfkill_unregister() and rfkill_destroy() outside the device_lock critical section. Store the rfkill pointer in a local variable before releasing the lock, then call rfkill_unregister() after releasing device_lock. This change is safe because rfkill_fop_write() holds rfkill_global_mutex while calling the rfkill callbacks, and rfkill_unregister() also acquires rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will wait for any ongoing callback to complete before proceeding, and device_del() is only called after rfkill_unregister() returns, preventing any use-after-free. The similar lock ordering in nfc_register_device() (device_lock -&amp;gt; rfkill_global_mutex via rfkill…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 222 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write A deadlock can occur between nfc_unregister_device() and rfkill_fop_write() due to lock ordering inversion between device_lock and rfkill_global_mutex. The problematic lock order is: Thread A (rfkill_fop_write):   rfkill_fop_write()     mutex_lock(&amp;amp;rfkill_global_mutex)       rfkill_set_block()         nfc_rfkill_set_block()           nfc_dev_down()             device_lock(&amp;amp;dev-&amp;gt;dev)    &amp;lt;- waits for device_lock Thread B (nfc_unregister_device):   nfc_unregister_device()     device_lock(&amp;amp;dev-&amp;gt;dev)       rfkill_unregister()         mutex_lock(&amp;amp;rfkill_global_mutex)  &amp;lt;- waits for rfkill_global_mutex This creates a classic ABBA deadlock scenario. Fix this by moving rfkill_unregister() and rfkill_destroy() outside the device_lock critical section. Store the rfkill pointer in a local variable before releasing the lock, then call rfkill_unregister() after releasing device_lock. This change is safe because rfkill_fop_write() holds rfkill_global_mutex while calling the rfkill callbacks, and rfkill_unregister() also acquires rfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will wait for any ongoing callback to complete before proceeding, and device_del() is only called after rfkill_unregister() returns, preventing any use-after-free. The similar lock ordering in nfc_register_device() (device_lock -&amp;gt; rfkill_global_mutex via rfkill…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-71079</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-0086 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0086</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0086</guid>
    </item>
  </channel>
</rss>
