<?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>Sun, 04 Oct 2026 21:29:14 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-04620</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-04620</link>
      <description>bdu:2025-04620</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-04620</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-21943</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-21943</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-21943</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0333 — 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-2025-avi-0333</link>
      <description>certfr-2025-avi-0333</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0333</guid>
    </item>
    <item>
      <title>EUVD-2026-314110</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-314110</link>
      <description>EUVD-2026-314110</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-314110</guid>
    </item>
    <item>
      <title>fkie_cve-2025-21943</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-21943</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;gpio: aggregator: protect driver attr handlers against module unload&lt;/p&gt;
&lt;p&gt;Both new_device_store and delete_device_store touch module global
resources (e.g. gpio_aggregator_lock). To prevent race conditions with
module unload, a reference needs to be held.&lt;/p&gt;
&lt;p&gt;Add try_module_get() in these handlers.&lt;/p&gt;
&lt;p&gt;For new_device_store, this eliminates what appears to be the most dangerous
scenario: if an id is allocated from gpio_aggregator_idr but
platform_device_register has not yet been called or completed, a concurrent
module unload could fail to unregister/delete the device, leaving behind a
dangling platform device/GPIO forwarder. This can result in various issues.
The following simple reproducer demonstrates these problems:&lt;/p&gt;
&lt;p&gt;#!/bin/bash
  while :; do
    # note: whether &amp;#39;gpiochip0 0&amp;#39; exists or not does not matter.
    echo &amp;#39;gpiochip0 0&amp;#39; &amp;gt; /sys/bus/platform/drivers/gpio-aggregator/new_device
  done &amp;amp;
  while :; do
    modprobe gpio-aggregator
    modprobe -r gpio-aggregator
  done &amp;amp;
  wait&lt;/p&gt;
&lt;p&gt;Starting with the following warning, several kinds of warnings will appear
  and the system may become unstable:&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
  list_del corruption, ffff888103e2e980-&amp;gt;next is LIST_POISON1 (dead000000000100)
  WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120
  [...]
  RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120
  [...]
  Call Trace:
   &amp;lt;TASK&amp;gt;
   ? __list…&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;gpio: aggregator: protect driver attr handlers against module unload&lt;/p&gt;
&lt;p&gt;Both new_device_store and delete_device_store touch module global
resources (e.g. gpio_aggregator_lock). To prevent race conditions with
module unload, a reference needs to be held.&lt;/p&gt;
&lt;p&gt;Add try_module_get() in these handlers.&lt;/p&gt;
&lt;p&gt;For new_device_store, this eliminates what appears to be the most dangerous
scenario: if an id is allocated from gpio_aggregator_idr but
platform_device_register has not yet been called or completed, a concurrent
module unload could fail to unregister/delete the device, leaving behind a
dangling platform device/GPIO forwarder. This can result in various issues.
The following simple reproducer demonstrates these problems:&lt;/p&gt;
&lt;p&gt;#!/bin/bash
  while :; do
    # note: whether &amp;#39;gpiochip0 0&amp;#39; exists or not does not matter.
    echo &amp;#39;gpiochip0 0&amp;#39; &amp;gt; /sys/bus/platform/drivers/gpio-aggregator/new_device
  done &amp;amp;
  while :; do
    modprobe gpio-aggregator
    modprobe -r gpio-aggregator
  done &amp;amp;
  wait&lt;/p&gt;
&lt;p&gt;Starting with the following warning, several kinds of warnings will appear
  and the system may become unstable:&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
  list_del corruption, ffff888103e2e980-&amp;gt;next is LIST_POISON1 (dead000000000100)
  WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120
  [...]
  RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120
  [...]
  Call Trace:
   &amp;lt;TASK&amp;gt;
   ? __list…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-21943</guid>
    </item>
    <item>
      <title>GHSA-m7pp-g2rm-wrcq</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-m7pp-g2rm-wrcq</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;gpio: aggregator: protect driver attr handlers against module unload&lt;/p&gt;
&lt;p&gt;Both new_device_store and delete_device_store touch module global
resources (e.g. gpio_aggregator_lock). To prevent race conditions with
module unload, a reference needs to be held.&lt;/p&gt;
&lt;p&gt;Add try_module_get() in these handlers.&lt;/p&gt;
&lt;p&gt;For new_device_store, this eliminates what appears to be the most dangerous
scenario: if an id is allocated from gpio_aggregator_idr but
platform_device_register has not yet been called or completed, a concurrent
module unload could fail to unregister/delete the device, leaving behind a
dangling platform device/GPIO forwarder. This can result in various issues.
The following simple reproducer demonstrates these problems:&lt;/p&gt;
&lt;p&gt;#!/bin/bash
  while :; do
    # note: whether &amp;#39;gpiochip0 0&amp;#39; exists or not does not matter.
    echo &amp;#39;gpiochip0 0&amp;#39; &amp;gt; /sys/bus/platform/drivers/gpio-aggregator/new_device
  done &amp;amp;
  while :; do
    modprobe gpio-aggregator
    modprobe -r gpio-aggregator
  done &amp;amp;
  wait&lt;/p&gt;
&lt;p&gt;Starting with the following warning, several kinds of warnings will appear
  and the system may become unstable:&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
  list_del corruption, ffff888103e2e980-&amp;gt;next is LIST_POISON1 (dead000000000100)
  WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120
  [...]
  RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120
  [...]
  Call Trace:
   &amp;lt;TASK&amp;gt;
   ? __list…&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;gpio: aggregator: protect driver attr handlers against module unload&lt;/p&gt;
&lt;p&gt;Both new_device_store and delete_device_store touch module global
resources (e.g. gpio_aggregator_lock). To prevent race conditions with
module unload, a reference needs to be held.&lt;/p&gt;
&lt;p&gt;Add try_module_get() in these handlers.&lt;/p&gt;
&lt;p&gt;For new_device_store, this eliminates what appears to be the most dangerous
scenario: if an id is allocated from gpio_aggregator_idr but
platform_device_register has not yet been called or completed, a concurrent
module unload could fail to unregister/delete the device, leaving behind a
dangling platform device/GPIO forwarder. This can result in various issues.
The following simple reproducer demonstrates these problems:&lt;/p&gt;
&lt;p&gt;#!/bin/bash
  while :; do
    # note: whether &amp;#39;gpiochip0 0&amp;#39; exists or not does not matter.
    echo &amp;#39;gpiochip0 0&amp;#39; &amp;gt; /sys/bus/platform/drivers/gpio-aggregator/new_device
  done &amp;amp;
  while :; do
    modprobe gpio-aggregator
    modprobe -r gpio-aggregator
  done &amp;amp;
  wait&lt;/p&gt;
&lt;p&gt;Starting with the following warning, several kinds of warnings will appear
  and the system may become unstable:&lt;/p&gt;
&lt;p&gt;------------[ cut here ]------------
  list_del corruption, ffff888103e2e980-&amp;gt;next is LIST_POISON1 (dead000000000100)
  WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120
  [...]
  RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120
  [...]
  Call Trace:
   &amp;lt;TASK&amp;gt;
   ? __list…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-m7pp-g2rm-wrcq</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-21943 — gpio: aggregator: protect driver attr handlers against module unload</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-21943</link>
      <description>msrc_CVE-2025-21943</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-21943</guid>
    </item>
    <item>
      <title>OESA-2025-1409 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1409</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/ntfs3: Fix some memory leaks in an error handling path of &amp;amp;apos;log_replay()&amp;amp;apos;&lt;/p&gt;
&lt;p&gt;All error handling paths lead to &amp;amp;apos;out&amp;amp;apos; where many resources are freed.&lt;/p&gt;
&lt;p&gt;Do it as well here instead of a direct return, otherwise &amp;amp;apos;log&amp;amp;apos;, &amp;amp;apos;ra&amp;amp;apos; and
&amp;amp;apos;log-&amp;amp;gt;one_page_buf&amp;amp;apos; (at least) will leak.(CVE-2021-47660)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;list: fix a data-race around ep-&amp;amp;gt;rdllist&lt;/p&gt;
&lt;p&gt;ep_poll() first calls ep_events_available() with no lock held and checks
if ep-&amp;amp;gt;rdllist is empty by list_empty_careful(), which reads
rdllist-&amp;amp;gt;prev.  Thus all accesses to it need some protection to avoid
store/load-tearing.&lt;/p&gt;
&lt;p&gt;Note INIT_LIST_HEAD_RCU() already has the annotation for both prev
and next.&lt;/p&gt;
&lt;p&gt;Commit bf3b9f6372c4 (&amp;amp;quot;epoll: Add busy poll support to epoll with socket
fds.&amp;amp;quot;) added the first lockless ep_events_available(), and commit
c5a282e9635e (&amp;amp;quot;fs/epoll: reduce the scope of wq lock in epoll_wait()&amp;amp;quot;)
made some ep_events_available() calls lockless and added single call under
a lock, finally commit e59d3c64cba6 (&amp;amp;quot;epoll: eliminate unnecessary lock
for zero timeout&amp;amp;quot;) made the last ep_events_available() lockless.&lt;/p&gt;
&lt;p&gt;BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait&lt;/p&gt;
&lt;p&gt;write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0:
 INIT_LIST_HEAD include/linux…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/ntfs3: Fix some memory leaks in an error handling path of &amp;amp;apos;log_replay()&amp;amp;apos;&lt;/p&gt;
&lt;p&gt;All error handling paths lead to &amp;amp;apos;out&amp;amp;apos; where many resources are freed.&lt;/p&gt;
&lt;p&gt;Do it as well here instead of a direct return, otherwise &amp;amp;apos;log&amp;amp;apos;, &amp;amp;apos;ra&amp;amp;apos; and
&amp;amp;apos;log-&amp;amp;gt;one_page_buf&amp;amp;apos; (at least) will leak.(CVE-2021-47660)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;list: fix a data-race around ep-&amp;amp;gt;rdllist&lt;/p&gt;
&lt;p&gt;ep_poll() first calls ep_events_available() with no lock held and checks
if ep-&amp;amp;gt;rdllist is empty by list_empty_careful(), which reads
rdllist-&amp;amp;gt;prev.  Thus all accesses to it need some protection to avoid
store/load-tearing.&lt;/p&gt;
&lt;p&gt;Note INIT_LIST_HEAD_RCU() already has the annotation for both prev
and next.&lt;/p&gt;
&lt;p&gt;Commit bf3b9f6372c4 (&amp;amp;quot;epoll: Add busy poll support to epoll with socket
fds.&amp;amp;quot;) added the first lockless ep_events_available(), and commit
c5a282e9635e (&amp;amp;quot;fs/epoll: reduce the scope of wq lock in epoll_wait()&amp;amp;quot;)
made some ep_events_available() calls lockless and added single call under
a lock, finally commit e59d3c64cba6 (&amp;amp;quot;epoll: eliminate unnecessary lock
for zero timeout&amp;amp;quot;) made the last ep_events_available() lockless.&lt;/p&gt;
&lt;p&gt;BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait&lt;/p&gt;
&lt;p&gt;write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0:
 INIT_LIST_HEAD include/linux…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1409</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:01614-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:01614-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-2025:01614-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-21943</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21943</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 144 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: gpio: aggregator: protect driver attr handlers against module unload Both new_device_store and delete_device_store touch module global resources (e.g. gpio_aggregator_lock). To prevent race conditions with module unload, a reference needs to be held. Add try_module_get() in these handlers. For new_device_store, this eliminates what appears to be the most dangerous scenario: if an id is allocated from gpio_aggregator_idr but platform_device_register has not yet been called or completed, a concurrent module unload could fail to unregister/delete the device, leaving behind a dangling platform device/GPIO forwarder. This can result in various issues. The following simple reproducer demonstrates these problems:   #!/bin/bash   while :; do     # note: whether &amp;#39;gpiochip0 0&amp;#39; exists or not does not matter.     echo &amp;#39;gpiochip0 0&amp;#39; &amp;gt; /sys/bus/platform/drivers/gpio-aggregator/new_device   done &amp;amp;   while :; do     modprobe gpio-aggregator     modprobe -r gpio-aggregator   done &amp;amp;   wait   Starting with the following warning, several kinds of warnings will appear   and the system may become unstable:   ------------[ cut here ]------------   list_del corruption, ffff888103e2e980-&amp;gt;next is LIST_POISON1 (dead000000000100)   WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120   [...]   RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120   [...]   Call Trace:    &amp;lt;TASK&amp;gt;    ? __list_del_en…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 144 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: gpio: aggregator: protect driver attr handlers against module unload Both new_device_store and delete_device_store touch module global resources (e.g. gpio_aggregator_lock). To prevent race conditions with module unload, a reference needs to be held. Add try_module_get() in these handlers. For new_device_store, this eliminates what appears to be the most dangerous scenario: if an id is allocated from gpio_aggregator_idr but platform_device_register has not yet been called or completed, a concurrent module unload could fail to unregister/delete the device, leaving behind a dangling platform device/GPIO forwarder. This can result in various issues. The following simple reproducer demonstrates these problems:   #!/bin/bash   while :; do     # note: whether &amp;#39;gpiochip0 0&amp;#39; exists or not does not matter.     echo &amp;#39;gpiochip0 0&amp;#39; &amp;gt; /sys/bus/platform/drivers/gpio-aggregator/new_device   done &amp;amp;   while :; do     modprobe gpio-aggregator     modprobe -r gpio-aggregator   done &amp;amp;   wait   Starting with the following warning, several kinds of warnings will appear   and the system may become unstable:   ------------[ cut here ]------------   list_del corruption, ffff888103e2e980-&amp;gt;next is LIST_POISON1 (dead000000000100)   WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120   [...]   RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120   [...]   Call Trace:    &amp;lt;TASK&amp;gt;    ? __list_del_en…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21943</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-0683 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0683</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial-of-Service auszulösen und um nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial-of-Service auszulösen und um nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0683</guid>
    </item>
  </channel>
</rss>
