<?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>Tue, 06 Oct 2026 17:26:18 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-21943 — gpio: aggregator: protect driver attr handlers against module unload</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-21943</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;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;&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;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/cve-2025-21943</guid>
    </item>
  </channel>
</rss>
