<?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-02T18:54:02.249753+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/bdu:2026-11062</id>
    <title>bdu:2026-11062</title>
    <updated>2026-10-02T18:54:02.484625+00:00</updated>
    <content>bdu:2026-11062</content>
    <link href="https://cve.radiocsirt.org/vuln/bdu:2026-11062"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2025-71079</id>
    <title>BELL-CVE-2025-71079</title>
    <updated>2026-10-02T18:54:02.484676+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-2025-71079"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0166</id>
    <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>
    <updated>2026-10-02T18:54:02.484708+00:00</updated>
    <content>certfr-2026-avi-0166</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2026-avi-0166"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-364612</id>
    <title>EUVD-2026-364612</title>
    <updated>2026-10-02T18:54:02.484726+00:00</updated>
    <content>EUVD-2026-364612</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-364612"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2025-71079</id>
    <title>fkie_cve-2025-71079</title>
    <updated>2026-10-02T18:54:02.484738+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>net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write</p>
<p>A deadlock can occur between nfc_unregister_device() and rfkill_fop_write()
due to lock ordering inversion between device_lock and rfkill_global_mutex.</p>
<p>The problematic lock order is:</p>
<p>Thread A (rfkill_fop_write):
  rfkill_fop_write()
    mutex_lock(&amp;rfkill_global_mutex)
      rfkill_set_block()
        nfc_rfkill_set_block()
          nfc_dev_down()
            device_lock(&amp;dev-&gt;dev)    &lt;- waits for device_lock</p>
<p>Thread B (nfc_unregister_device):
  nfc_unregister_device()
    device_lock(&amp;dev-&gt;dev)
      rfkill_unregister()
        mutex_lock(&amp;rfkill_global_mutex)  &lt;- waits for rfkill_global_mutex</p>
<p>This creates a classic ABBA deadlock scenario.</p>
<p>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.</p>
<p>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.</p>
<p>The similar lock ordering in nfc_register_device() (device_lock -&gt;
rfkill_global_mutex v…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2025-71079"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-q63x-gg9g-q34f</id>
    <title>GHSA-q63x-gg9g-q34f</title>
    <updated>2026-10-02T18:54:02.484784+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>net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write</p>
<p>A deadlock can occur between nfc_unregister_device() and rfkill_fop_write()
due to lock ordering inversion between device_lock and rfkill_global_mutex.</p>
<p>The problematic lock order is:</p>
<p>Thread A (rfkill_fop_write):
  rfkill_fop_write()
    mutex_lock(&amp;rfkill_global_mutex)
      rfkill_set_block()
        nfc_rfkill_set_block()
          nfc_dev_down()
            device_lock(&amp;dev-&gt;dev)    &lt;- waits for device_lock</p>
<p>Thread B (nfc_unregister_device):
  nfc_unregister_device()
    device_lock(&amp;dev-&gt;dev)
      rfkill_unregister()
        mutex_lock(&amp;rfkill_global_mutex)  &lt;- waits for rfkill_global_mutex</p>
<p>This creates a classic ABBA deadlock scenario.</p>
<p>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.</p>
<p>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.</p>
<p>The similar lock ordering in nfc_register_device() (device_lock -&gt;
rfkill_global_mutex v…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-q63x-gg9g-q34f"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/icsa-26-209-04</id>
    <title>ICSA-26-209-04 — Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP</title>
    <updated>2026-10-02T18:54:02.484818+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>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).</p>
<p>Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/icsa-26-209-04"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2025-71079</id>
    <title>msrc_CVE-2025-71079 — net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write</title>
    <updated>2026-10-02T18:54:02.484991+00:00</updated>
    <content>msrc_CVE-2025-71079</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2025-71079"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20287-1</id>
    <title>openSUSE-SU-2026:20287-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-02T18:54:02.485008+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:20287-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ssa-019113</id>
    <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>
    <updated>2026-10-02T18:54:02.485141+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>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).</p>
<p>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.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ssa-019113"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2026:0587-1</id>
    <title>SUSE-SU-2026:0587-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-02T18:54:02.485372+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:0587-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-71079</id>
    <title>UBUNTU-CVE-2025-71079</title>
    <updated>2026-10-02T18:54:02.485487+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> 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</p>
<p>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;rfkill_global_mutex)       rfkill_set_block()         nfc_rfkill_set_block()           nfc_dev_down()             device_lock(&amp;dev-&gt;dev)    &lt;- waits for device_lock Thread B (nfc_unregister_device):   nfc_unregister_device()     device_lock(&amp;dev-&gt;dev)       rfkill_unregister()         mutex_lock(&amp;rfkill_global_mutex)  &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 -&gt; rfkill_global_mutex via rfkill…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-71079"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0086</id>
    <title>WID-SEC-W-2026-0086 — Linux Kernel: Mehrere Schwachstellen</title>
    <updated>2026-10-02T18:54:02.485752+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0086"/>
  </entry>
</feed>
