<?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:15:04 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-07711</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-07711</link>
      <description>bdu:2025-07711</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-07711</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-21701</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-21701</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-21701</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0277 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Elles permettent à un attaquant de p…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0277</link>
      <description>certfr-2025-avi-0277</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0277</guid>
    </item>
    <item>
      <title>EUVD-2026-346634</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-346634</link>
      <description>EUVD-2026-346634</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-346634</guid>
    </item>
    <item>
      <title>fkie_cve-2025-21701</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-21701</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: avoid race between device unregistration and ethnl ops&lt;/p&gt;
&lt;p&gt;The following trace can be seen if a device is being unregistered while
its number of channels are being modified.&lt;/p&gt;
&lt;p&gt;DEBUG_LOCKS_WARN_ON(lock-&amp;gt;magic != lock)
  WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120
  CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771
  RIP: 0010:__mutex_lock+0xc8a/0x1120
  Call Trace:
   &amp;lt;TASK&amp;gt;
   ethtool_check_max_channel+0x1ea/0x880
   ethnl_set_channels+0x3c3/0xb10
   ethnl_default_set_doit+0x306/0x650
   genl_family_rcv_msg_doit+0x1e3/0x2c0
   genl_rcv_msg+0x432/0x6f0
   netlink_rcv_skb+0x13d/0x3b0
   genl_rcv+0x28/0x40
   netlink_unicast+0x42e/0x720
   netlink_sendmsg+0x765/0xc20
   __sys_sendto+0x3ac/0x420
   __x64_sys_sendto+0xe0/0x1c0
   do_syscall_64+0x95/0x180
   entry_SYSCALL_64_after_hwframe+0x76/0x7e&lt;/p&gt;
&lt;p&gt;This is because unregister_netdevice_many_notify might run before the
rtnl lock section of ethnl operations, eg. set_channels in the above
example. In this example the rss lock would be destroyed by the device
unregistration path before being used again, but in general running
ethnl operations while dismantle has started is not a good idea.&lt;/p&gt;
&lt;p&gt;Fix this by denying any operation on devices being unregistered. A check
was already there in ethnl_ops_begin, but not wide enough.&lt;/p&gt;
&lt;p&gt;Note that the same issue cannot be seen on the ioctl version
(__dev_ethtool) because the d…&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;net: avoid race between device unregistration and ethnl ops&lt;/p&gt;
&lt;p&gt;The following trace can be seen if a device is being unregistered while
its number of channels are being modified.&lt;/p&gt;
&lt;p&gt;DEBUG_LOCKS_WARN_ON(lock-&amp;gt;magic != lock)
  WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120
  CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771
  RIP: 0010:__mutex_lock+0xc8a/0x1120
  Call Trace:
   &amp;lt;TASK&amp;gt;
   ethtool_check_max_channel+0x1ea/0x880
   ethnl_set_channels+0x3c3/0xb10
   ethnl_default_set_doit+0x306/0x650
   genl_family_rcv_msg_doit+0x1e3/0x2c0
   genl_rcv_msg+0x432/0x6f0
   netlink_rcv_skb+0x13d/0x3b0
   genl_rcv+0x28/0x40
   netlink_unicast+0x42e/0x720
   netlink_sendmsg+0x765/0xc20
   __sys_sendto+0x3ac/0x420
   __x64_sys_sendto+0xe0/0x1c0
   do_syscall_64+0x95/0x180
   entry_SYSCALL_64_after_hwframe+0x76/0x7e&lt;/p&gt;
&lt;p&gt;This is because unregister_netdevice_many_notify might run before the
rtnl lock section of ethnl operations, eg. set_channels in the above
example. In this example the rss lock would be destroyed by the device
unregistration path before being used again, but in general running
ethnl operations while dismantle has started is not a good idea.&lt;/p&gt;
&lt;p&gt;Fix this by denying any operation on devices being unregistered. A check
was already there in ethnl_ops_begin, but not wide enough.&lt;/p&gt;
&lt;p&gt;Note that the same issue cannot be seen on the ioctl version
(__dev_ethtool) because the d…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-21701</guid>
    </item>
    <item>
      <title>GHSA-268v-p5rc-rhmv</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-268v-p5rc-rhmv</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: avoid race between device unregistration and ethnl ops&lt;/p&gt;
&lt;p&gt;The following trace can be seen if a device is being unregistered while
its number of channels are being modified.&lt;/p&gt;
&lt;p&gt;DEBUG_LOCKS_WARN_ON(lock-&amp;gt;magic != lock)
  WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120
  CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771
  RIP: 0010:__mutex_lock+0xc8a/0x1120
  Call Trace:
   &amp;lt;TASK&amp;gt;
   ethtool_check_max_channel+0x1ea/0x880
   ethnl_set_channels+0x3c3/0xb10
   ethnl_default_set_doit+0x306/0x650
   genl_family_rcv_msg_doit+0x1e3/0x2c0
   genl_rcv_msg+0x432/0x6f0
   netlink_rcv_skb+0x13d/0x3b0
   genl_rcv+0x28/0x40
   netlink_unicast+0x42e/0x720
   netlink_sendmsg+0x765/0xc20
   __sys_sendto+0x3ac/0x420
   __x64_sys_sendto+0xe0/0x1c0
   do_syscall_64+0x95/0x180
   entry_SYSCALL_64_after_hwframe+0x76/0x7e&lt;/p&gt;
&lt;p&gt;This is because unregister_netdevice_many_notify might run before the
rtnl lock section of ethnl operations, eg. set_channels in the above
example. In this example the rss lock would be destroyed by the device
unregistration path before being used again, but in general running
ethnl operations while dismantle has started is not a good idea.&lt;/p&gt;
&lt;p&gt;Fix this by denying any operation on devices being unregistered. A check
was already there in ethnl_ops_begin, but not wide enough.&lt;/p&gt;
&lt;p&gt;Note that the same issue cannot be seen on the ioctl version
(__dev_ethtool) because the d…&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;net: avoid race between device unregistration and ethnl ops&lt;/p&gt;
&lt;p&gt;The following trace can be seen if a device is being unregistered while
its number of channels are being modified.&lt;/p&gt;
&lt;p&gt;DEBUG_LOCKS_WARN_ON(lock-&amp;gt;magic != lock)
  WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120
  CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771
  RIP: 0010:__mutex_lock+0xc8a/0x1120
  Call Trace:
   &amp;lt;TASK&amp;gt;
   ethtool_check_max_channel+0x1ea/0x880
   ethnl_set_channels+0x3c3/0xb10
   ethnl_default_set_doit+0x306/0x650
   genl_family_rcv_msg_doit+0x1e3/0x2c0
   genl_rcv_msg+0x432/0x6f0
   netlink_rcv_skb+0x13d/0x3b0
   genl_rcv+0x28/0x40
   netlink_unicast+0x42e/0x720
   netlink_sendmsg+0x765/0xc20
   __sys_sendto+0x3ac/0x420
   __x64_sys_sendto+0xe0/0x1c0
   do_syscall_64+0x95/0x180
   entry_SYSCALL_64_after_hwframe+0x76/0x7e&lt;/p&gt;
&lt;p&gt;This is because unregister_netdevice_many_notify might run before the
rtnl lock section of ethnl operations, eg. set_channels in the above
example. In this example the rss lock would be destroyed by the device
unregistration path before being used again, but in general running
ethnl operations while dismantle has started is not a good idea.&lt;/p&gt;
&lt;p&gt;Fix this by denying any operation on devices being unregistered. A check
was already there in ethnl_ops_begin, but not wide enough.&lt;/p&gt;
&lt;p&gt;Note that the same issue cannot be seen on the ioctl version
(__dev_ethtool) because the d…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-268v-p5rc-rhmv</guid>
    </item>
    <item>
      <title>ICSA-25-162-05 — Siemens SIMATIC S7-1500 CPU family</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-25-162-05</link>
      <description>&lt;p&gt;sshd in OpenSSH 6.2 through 8.x before 8.8, when certain non-default configurations are used, allows privilege escalation because supplemental groups are not initialized as expected. Helper programs for AuthorizedKeysCommand and AuthorizedPrincipalsCommand may run with privileges associated with group memberships of the sshd process, if the configuration specifies running the command as a different user. A flaw was found in glibc. When the getaddrinfo function is called with the AF_UNSPEC address family and the system is configured with no-aaaa mode via /etc/resolv.conf, a DNS response via TCP larger than 2048 bytes can potentially disclose stack contents through the function returned address data, and may cause a crash. A flaw was found in glibc. In an extremely rare situation, the getaddrinfo function may access memory that has been freed, resulting in an application crash. This issue is only exploitable when a NSS module implements only the _nss_*_gethostbyname2_r and _nss_*_getcanonname_r hooks without implementing the _nss_*_gethostbyname3_r hook. The resolved name should return a large number of IPv6 and IPv4, and the call to the getaddrinfo function should have the AF_INET6 address family with AI_CANONNAME, AI_ALL and AI_V4MAPPED as flags. A buffer overflow was discovered in the GNU C Library&amp;#39;s dynamic loader ld.so while processing the GLIBC_TUNABLES environment variable. This issue could allow a local attacker to use maliciously crafted GLIBC_TUNABLES environment var…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;sshd in OpenSSH 6.2 through 8.x before 8.8, when certain non-default configurations are used, allows privilege escalation because supplemental groups are not initialized as expected. Helper programs for AuthorizedKeysCommand and AuthorizedPrincipalsCommand may run with privileges associated with group memberships of the sshd process, if the configuration specifies running the command as a different user. A flaw was found in glibc. When the getaddrinfo function is called with the AF_UNSPEC address family and the system is configured with no-aaaa mode via /etc/resolv.conf, a DNS response via TCP larger than 2048 bytes can potentially disclose stack contents through the function returned address data, and may cause a crash. A flaw was found in glibc. In an extremely rare situation, the getaddrinfo function may access memory that has been freed, resulting in an application crash. This issue is only exploitable when a NSS module implements only the _nss_*_gethostbyname2_r and _nss_*_getcanonname_r hooks without implementing the _nss_*_gethostbyname3_r hook. The resolved name should return a large number of IPv6 and IPv4, and the call to the getaddrinfo function should have the AF_INET6 address family with AI_CANONNAME, AI_ALL and AI_V4MAPPED as flags. A buffer overflow was discovered in the GNU C Library&amp;#39;s dynamic loader ld.so while processing the GLIBC_TUNABLES environment variable. This issue could allow a local attacker to use maliciously crafted GLIBC_TUNABLES environment var…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-25-162-05</guid>
    </item>
    <item>
      <title>OESA-2025-1446 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1446</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;ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_trans&lt;/p&gt;
&lt;p&gt;There is a kernel API ntb_mw_clear_trans() would pass 0 to both addr and
size. This would make xlate_pos negative.&lt;/p&gt;
&lt;p&gt;[   23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000
[   23.734158] ================================================================================
[   23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7
[   23.734418] shift exponent -1 is negative&lt;/p&gt;
&lt;p&gt;Ensuring xlate_pos is a positive or zero before BIT.(CVE-2023-53034)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()&lt;/p&gt;
&lt;p&gt;The &amp;amp;quot;submit-&amp;amp;gt;cmd[i].size&amp;amp;quot; and &amp;amp;quot;submit-&amp;amp;gt;cmd[i].offset&amp;amp;quot; variables are u32
values that come from the user via the submit_lookup_cmds() function.
This addition could lead to an integer wrapping bug so use size_add()
to prevent that.&lt;/p&gt;
&lt;p&gt;Patchwork: https://patchwork.freedesktop.org/patch/624696/(CVE-2024-52559)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/ntfs3: Mark inode as bad as soon as error detected in mi_enum_attr()&lt;/p&gt;
&lt;p&gt;Extended the `mi_enum_attr()` function interface with an additional
parameter, `struct ntfs_inode *ni`, to allow marking the inode
as bad as soon as an error i…&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;ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_trans&lt;/p&gt;
&lt;p&gt;There is a kernel API ntb_mw_clear_trans() would pass 0 to both addr and
size. This would make xlate_pos negative.&lt;/p&gt;
&lt;p&gt;[   23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000
[   23.734158] ================================================================================
[   23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7
[   23.734418] shift exponent -1 is negative&lt;/p&gt;
&lt;p&gt;Ensuring xlate_pos is a positive or zero before BIT.(CVE-2023-53034)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()&lt;/p&gt;
&lt;p&gt;The &amp;amp;quot;submit-&amp;amp;gt;cmd[i].size&amp;amp;quot; and &amp;amp;quot;submit-&amp;amp;gt;cmd[i].offset&amp;amp;quot; variables are u32
values that come from the user via the submit_lookup_cmds() function.
This addition could lead to an integer wrapping bug so use size_add()
to prevent that.&lt;/p&gt;
&lt;p&gt;Patchwork: https://patchwork.freedesktop.org/patch/624696/(CVE-2024-52559)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fs/ntfs3: Mark inode as bad as soon as error detected in mi_enum_attr()&lt;/p&gt;
&lt;p&gt;Extended the `mi_enum_attr()` function interface with an additional
parameter, `struct ntfs_inode *ni`, to allow marking the inode
as bad as soon as an error i…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1446</guid>
    </item>
    <item>
      <title>SSA-082556 — SSA-082556: Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP V3.1.5</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-082556</link>
      <description>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.5 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;
&lt;p&gt;Note: This SSA advises vulnerabilities for firmware version V3.1.5 only; for version V3.1.6 refer to SSA-019113.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.5 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;
&lt;p&gt;Note: This SSA advises vulnerabilities for firmware version V3.1.5 only; for version V3.1.6 refer to SSA-019113.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-082556</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:01919-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:01919-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:01919-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-21701</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21701</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: net: avoid race between device unregistration and ethnl ops The following trace can be seen if a device is being unregistered while its number of channels are being modified.   DEBUG_LOCKS_WARN_ON(lock-&amp;gt;magic != lock)   WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120   CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771   RIP: 0010:__mutex_lock+0xc8a/0x1120   Call Trace:    &amp;lt;TASK&amp;gt;    ethtool_check_max_channel+0x1ea/0x880    ethnl_set_channels+0x3c3/0xb10    ethnl_default_set_doit+0x306/0x650    genl_family_rcv_msg_doit+0x1e3/0x2c0    genl_rcv_msg+0x432/0x6f0    netlink_rcv_skb+0x13d/0x3b0    genl_rcv+0x28/0x40    netlink_unicast+0x42e/0x720    netlink_sendmsg+0x765/0xc20    __sys_sendto+0x3ac/0x420    __x64_sys_sendto+0xe0/0x1c0    do_syscall_64+0x95/0x180    entry_SYSCALL_64_after_hwframe+0x76/0x7e This is because unregister_netdevice_many_notify might run before the rtnl lock section of ethnl operations, eg. set_channels in the above example. In this example the rss lock would be destroyed by the device unregistration path before being used again, but in general running ethnl operations while dismantle has started is not a good idea. Fix this by denying any operation on devices being unregistered. A check was already there in ethnl_ops_begin, but not wide enough. Note that the same issue cannot be seen on the ioctl version (__dev_ethtool) because the device…&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: net: avoid race between device unregistration and ethnl ops The following trace can be seen if a device is being unregistered while its number of channels are being modified.   DEBUG_LOCKS_WARN_ON(lock-&amp;gt;magic != lock)   WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120   CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771   RIP: 0010:__mutex_lock+0xc8a/0x1120   Call Trace:    &amp;lt;TASK&amp;gt;    ethtool_check_max_channel+0x1ea/0x880    ethnl_set_channels+0x3c3/0xb10    ethnl_default_set_doit+0x306/0x650    genl_family_rcv_msg_doit+0x1e3/0x2c0    genl_rcv_msg+0x432/0x6f0    netlink_rcv_skb+0x13d/0x3b0    genl_rcv+0x28/0x40    netlink_unicast+0x42e/0x720    netlink_sendmsg+0x765/0xc20    __sys_sendto+0x3ac/0x420    __x64_sys_sendto+0xe0/0x1c0    do_syscall_64+0x95/0x180    entry_SYSCALL_64_after_hwframe+0x76/0x7e This is because unregister_netdevice_many_notify might run before the rtnl lock section of ethnl operations, eg. set_channels in the above example. In this example the rss lock would be destroyed by the device unregistration path before being used again, but in general running ethnl operations while dismantle has started is not a good idea. Fix this by denying any operation on devices being unregistered. A check was already there in ethnl_ops_begin, but not wide enough. Note that the same issue cannot be seen on the ioctl version (__dev_ethtool) because the device…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21701</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-0378 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0378</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um erhöhte Privilegien zu erlangen oder einen Denial of Service auszulösen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um erhöhte Privilegien zu erlangen oder einen Denial of Service auszulösen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0378</guid>
    </item>
  </channel>
</rss>
