<?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 21:35:09 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-11830</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-11830</link>
      <description>bdu:2025-11830</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-11830</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-37921</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-37921</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-37921</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0464 — 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-0464</link>
      <description>certfr-2025-avi-0464</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0464</guid>
    </item>
    <item>
      <title>EUVD-2026-346859</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-346859</link>
      <description>EUVD-2026-346859</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-346859</guid>
    </item>
    <item>
      <title>fkie_cve-2025-37921</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-37921</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;vxlan: vnifilter: Fix unlocked deletion of default FDB entry&lt;/p&gt;
&lt;p&gt;When a VNI is deleted from a VXLAN device in &amp;#39;vnifilter&amp;#39; mode, the FDB
entry associated with the default remote (assuming one was configured)
is deleted without holding the hash lock. This is wrong and will result
in a warning [1] being generated by the lockdep annotation that was
added by commit ebe642067455 (&amp;#34;vxlan: Create wrappers for FDB lookup&amp;#34;).&lt;/p&gt;
&lt;p&gt;Reproducer:&lt;/p&gt;
&lt;p&gt;# ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1
 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0
 # bridge vni del vni 10010 dev vx0&lt;/p&gt;
&lt;p&gt;Fix by acquiring the hash lock before the deletion and releasing it
afterwards. Blame the original commit that introduced the issue rather
than the one that exposed it.&lt;/p&gt;
&lt;p&gt;[1]
WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0
[...]
RIP: 0010:vxlan_find_mac+0x17f/0x1a0
[...]
Call Trace:
 &amp;lt;TASK&amp;gt;
 __vxlan_fdb_delete+0xbe/0x560
 vxlan_vni_delete_group+0x2ba/0x940
 vxlan_vni_del.isra.0+0x15f/0x580
 vxlan_process_vni_filter+0x38b/0x7b0
 vxlan_vnifilter_process+0x3bb/0x510
 rtnetlink_rcv_msg+0x2f7/0xb70
 netlink_rcv_skb+0x131/0x360
 netlink_unicast+0x426/0x710
 netlink_sendmsg+0x75a/0xc20
 __sock_sendmsg+0xc1/0x150
 ____sys_sendmsg+0x5aa/0x7b0
 ___sys_sendmsg+0xfc/0x180
 __sys_sendmsg+0x121/0x1b0
 do_syscall_64+0xbb/0x1d0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53&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;vxlan: vnifilter: Fix unlocked deletion of default FDB entry&lt;/p&gt;
&lt;p&gt;When a VNI is deleted from a VXLAN device in &amp;#39;vnifilter&amp;#39; mode, the FDB
entry associated with the default remote (assuming one was configured)
is deleted without holding the hash lock. This is wrong and will result
in a warning [1] being generated by the lockdep annotation that was
added by commit ebe642067455 (&amp;#34;vxlan: Create wrappers for FDB lookup&amp;#34;).&lt;/p&gt;
&lt;p&gt;Reproducer:&lt;/p&gt;
&lt;p&gt;# ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1
 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0
 # bridge vni del vni 10010 dev vx0&lt;/p&gt;
&lt;p&gt;Fix by acquiring the hash lock before the deletion and releasing it
afterwards. Blame the original commit that introduced the issue rather
than the one that exposed it.&lt;/p&gt;
&lt;p&gt;[1]
WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0
[...]
RIP: 0010:vxlan_find_mac+0x17f/0x1a0
[...]
Call Trace:
 &amp;lt;TASK&amp;gt;
 __vxlan_fdb_delete+0xbe/0x560
 vxlan_vni_delete_group+0x2ba/0x940
 vxlan_vni_del.isra.0+0x15f/0x580
 vxlan_process_vni_filter+0x38b/0x7b0
 vxlan_vnifilter_process+0x3bb/0x510
 rtnetlink_rcv_msg+0x2f7/0xb70
 netlink_rcv_skb+0x131/0x360
 netlink_unicast+0x426/0x710
 netlink_sendmsg+0x75a/0xc20
 __sock_sendmsg+0xc1/0x150
 ____sys_sendmsg+0x5aa/0x7b0
 ___sys_sendmsg+0xfc/0x180
 __sys_sendmsg+0x121/0x1b0
 do_syscall_64+0xbb/0x1d0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-37921</guid>
    </item>
    <item>
      <title>GHSA-x58j-hw5g-jqcq</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-x58j-hw5g-jqcq</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;vxlan: vnifilter: Fix unlocked deletion of default FDB entry&lt;/p&gt;
&lt;p&gt;When a VNI is deleted from a VXLAN device in &amp;#39;vnifilter&amp;#39; mode, the FDB
entry associated with the default remote (assuming one was configured)
is deleted without holding the hash lock. This is wrong and will result
in a warning [1] being generated by the lockdep annotation that was
added by commit ebe642067455 (&amp;#34;vxlan: Create wrappers for FDB lookup&amp;#34;).&lt;/p&gt;
&lt;p&gt;Reproducer:&lt;/p&gt;
&lt;p&gt;# ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1
 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0
 # bridge vni del vni 10010 dev vx0&lt;/p&gt;
&lt;p&gt;Fix by acquiring the hash lock before the deletion and releasing it
afterwards. Blame the original commit that introduced the issue rather
than the one that exposed it.&lt;/p&gt;
&lt;p&gt;[1]
WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0
[...]
RIP: 0010:vxlan_find_mac+0x17f/0x1a0
[...]
Call Trace:
 &amp;lt;TASK&amp;gt;
 __vxlan_fdb_delete+0xbe/0x560
 vxlan_vni_delete_group+0x2ba/0x940
 vxlan_vni_del.isra.0+0x15f/0x580
 vxlan_process_vni_filter+0x38b/0x7b0
 vxlan_vnifilter_process+0x3bb/0x510
 rtnetlink_rcv_msg+0x2f7/0xb70
 netlink_rcv_skb+0x131/0x360
 netlink_unicast+0x426/0x710
 netlink_sendmsg+0x75a/0xc20
 __sock_sendmsg+0xc1/0x150
 ____sys_sendmsg+0x5aa/0x7b0
 ___sys_sendmsg+0xfc/0x180
 __sys_sendmsg+0x121/0x1b0
 do_syscall_64+0xbb/0x1d0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53&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;vxlan: vnifilter: Fix unlocked deletion of default FDB entry&lt;/p&gt;
&lt;p&gt;When a VNI is deleted from a VXLAN device in &amp;#39;vnifilter&amp;#39; mode, the FDB
entry associated with the default remote (assuming one was configured)
is deleted without holding the hash lock. This is wrong and will result
in a warning [1] being generated by the lockdep annotation that was
added by commit ebe642067455 (&amp;#34;vxlan: Create wrappers for FDB lookup&amp;#34;).&lt;/p&gt;
&lt;p&gt;Reproducer:&lt;/p&gt;
&lt;p&gt;# ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1
 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0
 # bridge vni del vni 10010 dev vx0&lt;/p&gt;
&lt;p&gt;Fix by acquiring the hash lock before the deletion and releasing it
afterwards. Blame the original commit that introduced the issue rather
than the one that exposed it.&lt;/p&gt;
&lt;p&gt;[1]
WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0
[...]
RIP: 0010:vxlan_find_mac+0x17f/0x1a0
[...]
Call Trace:
 &amp;lt;TASK&amp;gt;
 __vxlan_fdb_delete+0xbe/0x560
 vxlan_vni_delete_group+0x2ba/0x940
 vxlan_vni_del.isra.0+0x15f/0x580
 vxlan_process_vni_filter+0x38b/0x7b0
 vxlan_vnifilter_process+0x3bb/0x510
 rtnetlink_rcv_msg+0x2f7/0xb70
 netlink_rcv_skb+0x131/0x360
 netlink_unicast+0x426/0x710
 netlink_sendmsg+0x75a/0xc20
 __sock_sendmsg+0xc1/0x150
 ____sys_sendmsg+0x5aa/0x7b0
 ___sys_sendmsg+0xfc/0x180
 __sys_sendmsg+0x121/0x1b0
 do_syscall_64+0xbb/0x1d0
 entry_SYSCALL_64_after_hwframe+0x4b/0x53&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-x58j-hw5g-jqcq</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-37921 — vxlan: vnifilter: Fix unlocked deletion of default FDB entry</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-37921</link>
      <description>msrc_CVE-2025-37921</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-37921</guid>
    </item>
    <item>
      <title>OESA-2025-1625 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1625</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: 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;xen: Fix the issue of resource not being properly released in xenbus_dev_probe()&lt;/p&gt;
&lt;p&gt;This patch fixes an issue in the function xenbus_dev_probe(). In the
xenbus_dev_probe() function, within the if (err) branch at line 313, the
program incorrectly returns err directly without releasing the resources
allocated by err = drv-&amp;amp;gt;probe(dev, id). As the return value is non-zero,
the upper layers assume the processing logic has failed. However, the probe
operation was performed earlier without a corresponding remove operation.
Since the probe actually allocates resources, failing to perform the remove
operation could lead to problems.&lt;/p&gt;
&lt;p&gt;To fix this issue, we followed the resource release logic of the
xenbus_dev_remove() function by adding a new block fail_remove before the
fail_put block. After entering the branch if (err) at line 313, the
function will use a goto statement to jump to the fail_remove block,
ensuring that the previously acquired resources are correctly released,
thus preventing the reference count leak.&lt;/p&gt;
&lt;p&gt;This bug was identified by an experimental static analysis tool developed
by our team. The tool specializes in analyzing reference count operations
and detecting potential issues where resources are not properly managed.
In this case, the tool flagged the missing release operation as a
potential problem, which led to the developm…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: 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;xen: Fix the issue of resource not being properly released in xenbus_dev_probe()&lt;/p&gt;
&lt;p&gt;This patch fixes an issue in the function xenbus_dev_probe(). In the
xenbus_dev_probe() function, within the if (err) branch at line 313, the
program incorrectly returns err directly without releasing the resources
allocated by err = drv-&amp;amp;gt;probe(dev, id). As the return value is non-zero,
the upper layers assume the processing logic has failed. However, the probe
operation was performed earlier without a corresponding remove operation.
Since the probe actually allocates resources, failing to perform the remove
operation could lead to problems.&lt;/p&gt;
&lt;p&gt;To fix this issue, we followed the resource release logic of the
xenbus_dev_remove() function by adding a new block fail_remove before the
fail_put block. After entering the branch if (err) at line 313, the
function will use a goto statement to jump to the fail_remove block,
ensuring that the previously acquired resources are correctly released,
thus preventing the reference count leak.&lt;/p&gt;
&lt;p&gt;This bug was identified by an experimental static analysis tool developed
by our team. The tool specializes in analyzing reference count operations
and detecting potential issues where resources are not properly managed.
In this case, the tool flagged the missing release operation as a
potential problem, which led to the developm…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1625</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:02249-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:02249-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:02249-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-37921</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-37921</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 120 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: vxlan: vnifilter: Fix unlocked deletion of default FDB entry When a VNI is deleted from a VXLAN device in &amp;#39;vnifilter&amp;#39; mode, the FDB entry associated with the default remote (assuming one was configured) is deleted without holding the hash lock. This is wrong and will result in a warning [1] being generated by the lockdep annotation that was added by commit ebe642067455 (&amp;#34;vxlan: Create wrappers for FDB lookup&amp;#34;). Reproducer:  # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1  # bridge vni add vni 10010 remote 198.51.100.1 dev vx0  # bridge vni del vni 10010 dev vx0 Fix by acquiring the hash lock before the deletion and releasing it afterwards. Blame the original commit that introduced the issue rather than the one that exposed it. [1] WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0 [...] RIP: 0010:vxlan_find_mac+0x17f/0x1a0 [...] Call Trace:  &amp;lt;TASK&amp;gt;  __vxlan_fdb_delete+0xbe/0x560  vxlan_vni_delete_group+0x2ba/0x940  vxlan_vni_del.isra.0+0x15f/0x580  vxlan_process_vni_filter+0x38b/0x7b0  vxlan_vnifilter_process+0x3bb/0x510  rtnetlink_rcv_msg+0x2f7/0xb70  netlink_rcv_skb+0x131/0x360  netlink_unicast+0x426/0x710  netlink_sendmsg+0x75a/0xc20  __sock_sendmsg+0xc1/0x150  ____sys_sendmsg+0x5aa/0x7b0  ___sys_sendmsg+0xfc/0x180  __sys_sendmsg+0x121/0x1b0  do_syscall_64+0xbb/0x1d0  entry_SYSCALL_64_after_hwframe+0x4b/0x53&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 120 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: vxlan: vnifilter: Fix unlocked deletion of default FDB entry When a VNI is deleted from a VXLAN device in &amp;#39;vnifilter&amp;#39; mode, the FDB entry associated with the default remote (assuming one was configured) is deleted without holding the hash lock. This is wrong and will result in a warning [1] being generated by the lockdep annotation that was added by commit ebe642067455 (&amp;#34;vxlan: Create wrappers for FDB lookup&amp;#34;). Reproducer:  # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1  # bridge vni add vni 10010 remote 198.51.100.1 dev vx0  # bridge vni del vni 10010 dev vx0 Fix by acquiring the hash lock before the deletion and releasing it afterwards. Blame the original commit that introduced the issue rather than the one that exposed it. [1] WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0 [...] RIP: 0010:vxlan_find_mac+0x17f/0x1a0 [...] Call Trace:  &amp;lt;TASK&amp;gt;  __vxlan_fdb_delete+0xbe/0x560  vxlan_vni_delete_group+0x2ba/0x940  vxlan_vni_del.isra.0+0x15f/0x580  vxlan_process_vni_filter+0x38b/0x7b0  vxlan_vnifilter_process+0x3bb/0x510  rtnetlink_rcv_msg+0x2f7/0xb70  netlink_rcv_skb+0x131/0x360  netlink_unicast+0x426/0x710  netlink_sendmsg+0x75a/0xc20  __sock_sendmsg+0xc1/0x150  ____sys_sendmsg+0x5aa/0x7b0  ___sys_sendmsg+0xfc/0x180  __sys_sendmsg+0x121/0x1b0  do_syscall_64+0xbb/0x1d0  entry_SYSCALL_64_after_hwframe+0x4b/0x53&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-37921</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-1114 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1114</link>
      <description>&lt;p&gt;Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff und weitere nicht spezifizierte Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff und weitere nicht spezifizierte Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1114</guid>
    </item>
  </channel>
</rss>
