<?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 16:04:27 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-00934</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-00934</link>
      <description>bdu:2025-00934</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-00934</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-39296</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-39296</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2024-39296</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0632 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0632</link>
      <description>certfr-2024-avi-0632</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0632</guid>
    </item>
    <item>
      <title>EUVD-2026-312912</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-312912</link>
      <description>EUVD-2026-312912</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-312912</guid>
    </item>
    <item>
      <title>fkie_cve-2024-39296</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-39296</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bonding: fix oops during rmmod&lt;/p&gt;
&lt;p&gt;&amp;#34;rmmod bonding&amp;#34; causes an oops ever since commit cc317ea3d927 (&amp;#34;bonding:
remove redundant NULL check in debugfs function&amp;#34;).  Here are the relevant
functions being called:&lt;/p&gt;
&lt;p&gt;bonding_exit()
  bond_destroy_debugfs()
    debugfs_remove_recursive(bonding_debug_root);
    bonding_debug_root = NULL; &amp;lt;--------- SET TO NULL HERE
  bond_netlink_fini()
    rtnl_link_unregister()
      __rtnl_link_unregister()
        unregister_netdevice_many_notify()
          bond_uninit()
            bond_debug_unregister()
              (commit removed check for bonding_debug_root == NULL)
              debugfs_remove()
              simple_recursive_removal()
                down_write() -&amp;gt; OOPS&lt;/p&gt;
&lt;p&gt;However, reverting the bad commit does not solve the problem completely
because the original code contains a race that could cause the same
oops, although it was much less likely to be triggered unintentionally:&lt;/p&gt;
&lt;p&gt;CPU1
  rmmod bonding
    bonding_exit()
      bond_destroy_debugfs()
        debugfs_remove_recursive(bonding_debug_root);&lt;/p&gt;
&lt;p&gt;CPU2
  echo -bond0 &amp;gt; /sys/class/net/bonding_masters
    bond_uninit()
      bond_debug_unregister()
        if (!bonding_debug_root)&lt;/p&gt;
&lt;p&gt;CPU1
        bonding_debug_root = NULL;&lt;/p&gt;
&lt;p&gt;So do NOT revert the bad commit (since the removed checks were racy
anyway), and instead change the order of actions taken during module
removal.  The same oops can also happen if there is an error during…&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;bonding: fix oops during rmmod&lt;/p&gt;
&lt;p&gt;&amp;#34;rmmod bonding&amp;#34; causes an oops ever since commit cc317ea3d927 (&amp;#34;bonding:
remove redundant NULL check in debugfs function&amp;#34;).  Here are the relevant
functions being called:&lt;/p&gt;
&lt;p&gt;bonding_exit()
  bond_destroy_debugfs()
    debugfs_remove_recursive(bonding_debug_root);
    bonding_debug_root = NULL; &amp;lt;--------- SET TO NULL HERE
  bond_netlink_fini()
    rtnl_link_unregister()
      __rtnl_link_unregister()
        unregister_netdevice_many_notify()
          bond_uninit()
            bond_debug_unregister()
              (commit removed check for bonding_debug_root == NULL)
              debugfs_remove()
              simple_recursive_removal()
                down_write() -&amp;gt; OOPS&lt;/p&gt;
&lt;p&gt;However, reverting the bad commit does not solve the problem completely
because the original code contains a race that could cause the same
oops, although it was much less likely to be triggered unintentionally:&lt;/p&gt;
&lt;p&gt;CPU1
  rmmod bonding
    bonding_exit()
      bond_destroy_debugfs()
        debugfs_remove_recursive(bonding_debug_root);&lt;/p&gt;
&lt;p&gt;CPU2
  echo -bond0 &amp;gt; /sys/class/net/bonding_masters
    bond_uninit()
      bond_debug_unregister()
        if (!bonding_debug_root)&lt;/p&gt;
&lt;p&gt;CPU1
        bonding_debug_root = NULL;&lt;/p&gt;
&lt;p&gt;So do NOT revert the bad commit (since the removed checks were racy
anyway), and instead change the order of actions taken during module
removal.  The same oops can also happen if there is an error during…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-39296</guid>
    </item>
    <item>
      <title>GHSA-rw9r-wqx2-72f7</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-rw9r-wqx2-72f7</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bonding: fix oops during rmmod&lt;/p&gt;
&lt;p&gt;&amp;#34;rmmod bonding&amp;#34; causes an oops ever since commit cc317ea3d927 (&amp;#34;bonding:
remove redundant NULL check in debugfs function&amp;#34;).  Here are the relevant
functions being called:&lt;/p&gt;
&lt;p&gt;bonding_exit()
  bond_destroy_debugfs()
    debugfs_remove_recursive(bonding_debug_root);
    bonding_debug_root = NULL; &amp;lt;--------- SET TO NULL HERE
  bond_netlink_fini()
    rtnl_link_unregister()
      __rtnl_link_unregister()
        unregister_netdevice_many_notify()
          bond_uninit()
            bond_debug_unregister()
              (commit removed check for bonding_debug_root == NULL)
              debugfs_remove()
              simple_recursive_removal()
                down_write() -&amp;gt; OOPS&lt;/p&gt;
&lt;p&gt;However, reverting the bad commit does not solve the problem completely
because the original code contains a race that could cause the same
oops, although it was much less likely to be triggered unintentionally:&lt;/p&gt;
&lt;p&gt;CPU1
  rmmod bonding
    bonding_exit()
      bond_destroy_debugfs()
        debugfs_remove_recursive(bonding_debug_root);&lt;/p&gt;
&lt;p&gt;CPU2
  echo -bond0 &amp;gt; /sys/class/net/bonding_masters
    bond_uninit()
      bond_debug_unregister()
        if (!bonding_debug_root)&lt;/p&gt;
&lt;p&gt;CPU1
        bonding_debug_root = NULL;&lt;/p&gt;
&lt;p&gt;So do NOT revert the bad commit (since the removed checks were racy
anyway), and instead change the order of actions taken during module
removal.  The same oops can also happen if there is an error during…&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;bonding: fix oops during rmmod&lt;/p&gt;
&lt;p&gt;&amp;#34;rmmod bonding&amp;#34; causes an oops ever since commit cc317ea3d927 (&amp;#34;bonding:
remove redundant NULL check in debugfs function&amp;#34;).  Here are the relevant
functions being called:&lt;/p&gt;
&lt;p&gt;bonding_exit()
  bond_destroy_debugfs()
    debugfs_remove_recursive(bonding_debug_root);
    bonding_debug_root = NULL; &amp;lt;--------- SET TO NULL HERE
  bond_netlink_fini()
    rtnl_link_unregister()
      __rtnl_link_unregister()
        unregister_netdevice_many_notify()
          bond_uninit()
            bond_debug_unregister()
              (commit removed check for bonding_debug_root == NULL)
              debugfs_remove()
              simple_recursive_removal()
                down_write() -&amp;gt; OOPS&lt;/p&gt;
&lt;p&gt;However, reverting the bad commit does not solve the problem completely
because the original code contains a race that could cause the same
oops, although it was much less likely to be triggered unintentionally:&lt;/p&gt;
&lt;p&gt;CPU1
  rmmod bonding
    bonding_exit()
      bond_destroy_debugfs()
        debugfs_remove_recursive(bonding_debug_root);&lt;/p&gt;
&lt;p&gt;CPU2
  echo -bond0 &amp;gt; /sys/class/net/bonding_masters
    bond_uninit()
      bond_debug_unregister()
        if (!bonding_debug_root)&lt;/p&gt;
&lt;p&gt;CPU1
        bonding_debug_root = NULL;&lt;/p&gt;
&lt;p&gt;So do NOT revert the bad commit (since the removed checks were racy
anyway), and instead change the order of actions taken during module
removal.  The same oops can also happen if there is an error during…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-rw9r-wqx2-72f7</guid>
    </item>
    <item>
      <title>OESA-2024-1836 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1836</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):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
media: lgdt3306a: Add a check against null-pointer-def&#13;
&#13;
The driver should check whether the client provides the platform_data.&#13;
&#13;
The following log reveals it:&#13;
&#13;
[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[   29.612820] Call Trace:
[   29.613030]  &amp;amp;lt;TASK&amp;amp;gt;
[   29.613201]  dump_stack_lvl+0x56/0x6f
[   29.613496]  ? kmemdup+0x30/0x40
[   29.613754]  print_report.cold+0x494/0x6b7
[   29.614082]  ? kmemdup+0x30/0x40
[   29.614340]  kasan_report+0x8a/0x190
[   29.614628]  ? kmemdup+0x30/0x40
[   29.614888]  kasan_check_range+0x14d/0x1d0
[   29.615213]  memcpy+0x20/0x60
[   29.615454]  kmemdup+0x30/0x40
[   29.615700]  lgdt3306a_probe+0x52/0x310
[   29.616339]  i2c_device_probe+0x951/0xa90(CVE-2022-48772)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline&#13;
&#13;
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
interrupt affinity reconfiguration via procfs. Instead, the change is
deferred until the next instance of the interrupt being triggered on the
original CPU.&#13;
&#13;
When the interrupt next triggers on the original CPU, the new affinity is
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
but the old vector o…&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):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
media: lgdt3306a: Add a check against null-pointer-def&#13;
&#13;
The driver should check whether the client provides the platform_data.&#13;
&#13;
The following log reveals it:&#13;
&#13;
[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[   29.612820] Call Trace:
[   29.613030]  &amp;amp;lt;TASK&amp;amp;gt;
[   29.613201]  dump_stack_lvl+0x56/0x6f
[   29.613496]  ? kmemdup+0x30/0x40
[   29.613754]  print_report.cold+0x494/0x6b7
[   29.614082]  ? kmemdup+0x30/0x40
[   29.614340]  kasan_report+0x8a/0x190
[   29.614628]  ? kmemdup+0x30/0x40
[   29.614888]  kasan_check_range+0x14d/0x1d0
[   29.615213]  memcpy+0x20/0x60
[   29.615454]  kmemdup+0x30/0x40
[   29.615700]  lgdt3306a_probe+0x52/0x310
[   29.616339]  i2c_device_probe+0x951/0xa90(CVE-2022-48772)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline&#13;
&#13;
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
interrupt affinity reconfiguration via procfs. Instead, the change is
deferred until the next instance of the interrupt being triggered on the
original CPU.&#13;
&#13;
When the interrupt next triggers on the original CPU, the new affinity is
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
but the old vector o…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1836</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:2571-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:2571-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-2024:2571-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-39296</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-39296</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 78 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bonding: fix oops during rmmod &amp;#34;rmmod bonding&amp;#34; causes an oops ever since commit cc317ea3d927 (&amp;#34;bonding: remove redundant NULL check in debugfs function&amp;#34;).  Here are the relevant functions being called: bonding_exit()   bond_destroy_debugfs()     debugfs_remove_recursive(bonding_debug_root);     bonding_debug_root = NULL; &amp;lt;--------- SET TO NULL HERE   bond_netlink_fini()     rtnl_link_unregister()       __rtnl_link_unregister()         unregister_netdevice_many_notify()           bond_uninit()             bond_debug_unregister()               (commit removed check for bonding_debug_root == NULL)               debugfs_remove()               simple_recursive_removal()                 down_write() -&amp;gt; OOPS However, reverting the bad commit does not solve the problem completely because the original code contains a race that could cause the same oops, although it was much less likely to be triggered unintentionally: CPU1   rmmod bonding     bonding_exit()       bond_destroy_debugfs()         debugfs_remove_recursive(bonding_debug_root); CPU2   echo -bond0 &amp;gt; /sys/class/net/bonding_masters     bond_uninit()       bond_debug_unregister()         if (!bonding_debug_root) CPU1         bonding_debug_root = NULL; So do NOT revert the bad commit (since the removed checks were racy anyway), and instead change the order of actions taken during module removal.  The same oops can also happen if there is an error during module…&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 78 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bonding: fix oops during rmmod &amp;#34;rmmod bonding&amp;#34; causes an oops ever since commit cc317ea3d927 (&amp;#34;bonding: remove redundant NULL check in debugfs function&amp;#34;).  Here are the relevant functions being called: bonding_exit()   bond_destroy_debugfs()     debugfs_remove_recursive(bonding_debug_root);     bonding_debug_root = NULL; &amp;lt;--------- SET TO NULL HERE   bond_netlink_fini()     rtnl_link_unregister()       __rtnl_link_unregister()         unregister_netdevice_many_notify()           bond_uninit()             bond_debug_unregister()               (commit removed check for bonding_debug_root == NULL)               debugfs_remove()               simple_recursive_removal()                 down_write() -&amp;gt; OOPS However, reverting the bad commit does not solve the problem completely because the original code contains a race that could cause the same oops, although it was much less likely to be triggered unintentionally: CPU1   rmmod bonding     bonding_exit()       bond_destroy_debugfs()         debugfs_remove_recursive(bonding_debug_root); CPU2   echo -bond0 &amp;gt; /sys/class/net/bonding_masters     bond_uninit()       bond_debug_unregister()         if (!bonding_debug_root) CPU1         bonding_debug_root = NULL; So do NOT revert the bad commit (since the removed checks were racy anyway), and instead change the order of actions taken during module removal.  The same oops can also happen if there is an error during module…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-39296</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1451 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1451</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1451</guid>
    </item>
  </channel>
</rss>
