<?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>Sat, 03 Oct 2026 06:05:42 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-12223</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-12223</link>
      <description>bdu:2025-12223</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-12223</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-56599</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-56599</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-2024-56599</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0047 — De multiples vulnérabilités ont été découvertes dans les produits SUSE. Certaines d'entre elles permettent à un attaqua…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0047</link>
      <description>certfr-2025-avi-0047</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0047</guid>
    </item>
    <item>
      <title>EUVD-2026-313752</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-313752</link>
      <description>EUVD-2026-313752</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-313752</guid>
    </item>
    <item>
      <title>fkie_cve-2024-56599</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-56599</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;wifi: ath10k: avoid NULL pointer error during sdio remove&lt;/p&gt;
&lt;p&gt;When running &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will free sdio
workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON
is set to yes, kernel panic will happen:
Call trace:
 destroy_workqueue+0x1c/0x258
 ath10k_sdio_remove+0x84/0x94
 sdio_bus_remove+0x50/0x16c
 device_release_driver_internal+0x188/0x25c
 device_driver_detach+0x20/0x2c&lt;/p&gt;
&lt;p&gt;This is because during &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will call
ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()
will finally be called in ath10k_core_destroy(). This function will free
struct cfg80211_registered_device *rdev and all its members, including
wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio
workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.&lt;/p&gt;
&lt;p&gt;After device release, destroy_workqueue() will use NULL pointer then the
kernel panic happen.&lt;/p&gt;
&lt;p&gt;Call trace:
ath10k_sdio_remove
  -&amp;gt;ath10k_core_unregister
    ……
    -&amp;gt;ath10k_core_stop
      -&amp;gt;ath10k_hif_stop
        -&amp;gt;ath10k_sdio_irq_disable
    -&amp;gt;ath10k_hif_power_down
      -&amp;gt;del_timer_sync(&amp;amp;ar_sdio-&amp;gt;sleep_timer)
  -&amp;gt;ath10k_core_destroy
    -&amp;gt;ath10k_mac_destroy
      -&amp;gt;ieee80211_free_hw
        -&amp;gt;wiphy_free
    ……
          -&amp;gt;wiphy_dev_release
  -&amp;gt;destroy_workqueue&lt;/p&gt;
&lt;p&gt;Need to call destroy_workqueue() before ath10k_core_destroy(), free
the work queue buffer first and then free pointer of…&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;wifi: ath10k: avoid NULL pointer error during sdio remove&lt;/p&gt;
&lt;p&gt;When running &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will free sdio
workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON
is set to yes, kernel panic will happen:
Call trace:
 destroy_workqueue+0x1c/0x258
 ath10k_sdio_remove+0x84/0x94
 sdio_bus_remove+0x50/0x16c
 device_release_driver_internal+0x188/0x25c
 device_driver_detach+0x20/0x2c&lt;/p&gt;
&lt;p&gt;This is because during &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will call
ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()
will finally be called in ath10k_core_destroy(). This function will free
struct cfg80211_registered_device *rdev and all its members, including
wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio
workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.&lt;/p&gt;
&lt;p&gt;After device release, destroy_workqueue() will use NULL pointer then the
kernel panic happen.&lt;/p&gt;
&lt;p&gt;Call trace:
ath10k_sdio_remove
  -&amp;gt;ath10k_core_unregister
    ……
    -&amp;gt;ath10k_core_stop
      -&amp;gt;ath10k_hif_stop
        -&amp;gt;ath10k_sdio_irq_disable
    -&amp;gt;ath10k_hif_power_down
      -&amp;gt;del_timer_sync(&amp;amp;ar_sdio-&amp;gt;sleep_timer)
  -&amp;gt;ath10k_core_destroy
    -&amp;gt;ath10k_mac_destroy
      -&amp;gt;ieee80211_free_hw
        -&amp;gt;wiphy_free
    ……
          -&amp;gt;wiphy_dev_release
  -&amp;gt;destroy_workqueue&lt;/p&gt;
&lt;p&gt;Need to call destroy_workqueue() before ath10k_core_destroy(), free
the work queue buffer first and then free pointer of…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-56599</guid>
    </item>
    <item>
      <title>GHSA-h88r-39vx-9655</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-h88r-39vx-9655</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;wifi: ath10k: avoid NULL pointer error during sdio remove&lt;/p&gt;
&lt;p&gt;When running &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will free sdio
workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON
is set to yes, kernel panic will happen:
Call trace:
 destroy_workqueue+0x1c/0x258
 ath10k_sdio_remove+0x84/0x94
 sdio_bus_remove+0x50/0x16c
 device_release_driver_internal+0x188/0x25c
 device_driver_detach+0x20/0x2c&lt;/p&gt;
&lt;p&gt;This is because during &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will call
ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()
will finally be called in ath10k_core_destroy(). This function will free
struct cfg80211_registered_device *rdev and all its members, including
wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio
workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.&lt;/p&gt;
&lt;p&gt;After device release, destroy_workqueue() will use NULL pointer then the
kernel panic happen.&lt;/p&gt;
&lt;p&gt;Call trace:
ath10k_sdio_remove
  -&amp;gt;ath10k_core_unregister
    ……
    -&amp;gt;ath10k_core_stop
      -&amp;gt;ath10k_hif_stop
        -&amp;gt;ath10k_sdio_irq_disable
    -&amp;gt;ath10k_hif_power_down
      -&amp;gt;del_timer_sync(&amp;amp;ar_sdio-&amp;gt;sleep_timer)
  -&amp;gt;ath10k_core_destroy
    -&amp;gt;ath10k_mac_destroy
      -&amp;gt;ieee80211_free_hw
        -&amp;gt;wiphy_free
    ……
          -&amp;gt;wiphy_dev_release
  -&amp;gt;destroy_workqueue&lt;/p&gt;
&lt;p&gt;Need to call destroy_workqueue() before ath10k_core_destroy(), free
the work queue buffer first and then free pointer of…&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;wifi: ath10k: avoid NULL pointer error during sdio remove&lt;/p&gt;
&lt;p&gt;When running &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will free sdio
workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON
is set to yes, kernel panic will happen:
Call trace:
 destroy_workqueue+0x1c/0x258
 ath10k_sdio_remove+0x84/0x94
 sdio_bus_remove+0x50/0x16c
 device_release_driver_internal+0x188/0x25c
 device_driver_detach+0x20/0x2c&lt;/p&gt;
&lt;p&gt;This is because during &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will call
ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()
will finally be called in ath10k_core_destroy(). This function will free
struct cfg80211_registered_device *rdev and all its members, including
wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio
workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.&lt;/p&gt;
&lt;p&gt;After device release, destroy_workqueue() will use NULL pointer then the
kernel panic happen.&lt;/p&gt;
&lt;p&gt;Call trace:
ath10k_sdio_remove
  -&amp;gt;ath10k_core_unregister
    ……
    -&amp;gt;ath10k_core_stop
      -&amp;gt;ath10k_hif_stop
        -&amp;gt;ath10k_sdio_irq_disable
    -&amp;gt;ath10k_hif_power_down
      -&amp;gt;del_timer_sync(&amp;amp;ar_sdio-&amp;gt;sleep_timer)
  -&amp;gt;ath10k_core_destroy
    -&amp;gt;ath10k_mac_destroy
      -&amp;gt;ieee80211_free_hw
        -&amp;gt;wiphy_free
    ……
          -&amp;gt;wiphy_dev_release
  -&amp;gt;destroy_workqueue&lt;/p&gt;
&lt;p&gt;Need to call destroy_workqueue() before ath10k_core_destroy(), free
the work queue buffer first and then free pointer of…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-h88r-39vx-9655</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-56599 — wifi: ath10k: avoid NULL pointer error during sdio remove</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-56599</link>
      <description>msrc_CVE-2024-56599</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-56599</guid>
    </item>
    <item>
      <title>OESA-2025-2882 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-2882</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: 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:tcp_metrics: validate source addr lengthI don t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn t have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).(CVE-2024-42154)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:resource: fix region_intersects() vs add_memory_driver_managed()On a system with CXL memory, the resource tree (/proc/iomem) related toCXL memory may look like something as follows.490000000-50fffffff : CXL Window 0  490000000-50fffffff : region0    490000000-50fffffff : dax0.0      490000000-50fffffff : System RAM (kmem)Because drivers/dax/kmem.c calls add_memory_driver_managed() duringonlining CXL memory, which makes  System RAM (kmem)  a descendant of  CXLWindow X .  This confuses region_intersects(), which expects all  SystemRAM  resources to be at the top level of iomem_resource.  This can lead tobugs.For example, when the following command line is executed to write somememory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 &amp;amp;lt;&amp;amp;lt; 10)) seek=$((0x490000000 &amp;amp;gt;&amp;amp;gt; 10)) count=1 dd: error writing  /dev/mem : Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/sthe command fails as expected.  However, the error code is wrong.  Itshould be  Operation not permitted…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: 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:tcp_metrics: validate source addr lengthI don t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn t have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).(CVE-2024-42154)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:resource: fix region_intersects() vs add_memory_driver_managed()On a system with CXL memory, the resource tree (/proc/iomem) related toCXL memory may look like something as follows.490000000-50fffffff : CXL Window 0  490000000-50fffffff : region0    490000000-50fffffff : dax0.0      490000000-50fffffff : System RAM (kmem)Because drivers/dax/kmem.c calls add_memory_driver_managed() duringonlining CXL memory, which makes  System RAM (kmem)  a descendant of  CXLWindow X .  This confuses region_intersects(), which expects all  SystemRAM  resources to be at the top level of iomem_resource.  This can lead tobugs.For example, when the following command line is executed to write somememory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 &amp;amp;lt;&amp;amp;lt; 10)) seek=$((0x490000000 &amp;amp;gt;&amp;amp;gt; 10)) count=1 dd: error writing  /dev/mem : Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/sthe command fails as expected.  However, the error code is wrong.  Itshould be  Operation not permitted…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-2882</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:0117-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:0117-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:0117-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-56599</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-56599</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, 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, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3 and 185 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: avoid NULL pointer error during sdio remove When running &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace:  destroy_workqueue+0x1c/0x258  ath10k_sdio_remove+0x84/0x94  sdio_bus_remove+0x50/0x16c  device_release_driver_internal+0x188/0x25c  device_driver_detach+0x20/0x2c This is because during &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON. After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen. Call trace: ath10k_sdio_remove   -&amp;gt;ath10k_core_unregister     ……     -&amp;gt;ath10k_core_stop       -&amp;gt;ath10k_hif_stop         -&amp;gt;ath10k_sdio_irq_disable     -&amp;gt;ath10k_hif_power_down       -&amp;gt;del_timer_sync(&amp;amp;ar_sdio-&amp;gt;sleep_timer)   -&amp;gt;ath10k_core_destroy     -&amp;gt;ath10k_mac_destroy       -&amp;gt;ieee80211_free_hw         -&amp;gt;wiphy_free     ……           -&amp;gt;wiphy_dev_release   -&amp;gt;destroy_workqueue Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, 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, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3 and 185 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: avoid NULL pointer error during sdio remove When running &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace:  destroy_workqueue+0x1c/0x258  ath10k_sdio_remove+0x84/0x94  sdio_bus_remove+0x50/0x16c  device_release_driver_internal+0x188/0x25c  device_driver_detach+0x20/0x2c This is because during &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON. After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen. Call trace: ath10k_sdio_remove   -&amp;gt;ath10k_core_unregister     ……     -&amp;gt;ath10k_core_stop       -&amp;gt;ath10k_hif_stop         -&amp;gt;ath10k_sdio_irq_disable     -&amp;gt;ath10k_hif_power_down       -&amp;gt;del_timer_sync(&amp;amp;ar_sdio-&amp;gt;sleep_timer)   -&amp;gt;ath10k_core_destroy     -&amp;gt;ath10k_mac_destroy       -&amp;gt;ieee80211_free_hw         -&amp;gt;wiphy_free     ……           -&amp;gt;wiphy_dev_release   -&amp;gt;destroy_workqueue Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-56599</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-3762 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3762</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und um nicht näher beschriebene Effekte zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen und um nicht näher beschriebene Effekte zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3762</guid>
    </item>
  </channel>
</rss>
