<?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>Fri, 02 Oct 2026 16:26:27 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-01484</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-01484</link>
      <description>bdu:2025-01484</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-01484</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-21682</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-21682</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-21682</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0133 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Elles permettent à un attaquant de provoqu…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0133</link>
      <description>certfr-2025-avi-0133</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0133</guid>
    </item>
    <item>
      <title>cnvd-2025-03424</title>
      <link>https://cve.radiocsirt.org/vuln/cnvd-2025-03424</link>
      <description>cnvd-2025-03424</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cnvd-2025-03424</guid>
    </item>
    <item>
      <title>EUVD-2026-364483</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-364483</link>
      <description>EUVD-2026-364483</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-364483</guid>
    </item>
    <item>
      <title>fkie_cve-2025-21682</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-21682</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;eth: bnxt: always recalculate features after XDP clearing, fix null-deref&lt;/p&gt;
&lt;p&gt;Recalculate features when XDP is detached.&lt;/p&gt;
&lt;p&gt;Before:
  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
  # ip li set dev eth0 xdp off
  # ethtool -k eth0 | grep gro
  rx-gro-hw: off [requested on]&lt;/p&gt;
&lt;p&gt;After:
  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
  # ip li set dev eth0 xdp off
  # ethtool -k eth0 | grep gro
  rx-gro-hw: on&lt;/p&gt;
&lt;p&gt;The fact that HW-GRO doesn&amp;#39;t get re-enabled automatically is just
a minor annoyance. The real issue is that the features will randomly
come back during another reconfiguration which just happens to invoke
netdev_update_features(). The driver doesn&amp;#39;t handle reconfiguring
two things at a time very robustly.&lt;/p&gt;
&lt;p&gt;Starting with commit 98ba1d931f61 (&amp;#34;bnxt_en: Fix RSS logic in
__bnxt_reserve_rings()&amp;#34;) we only reconfigure the RSS hash table
if the &amp;#34;effective&amp;#34; number of Rx rings has changed. If HW-GRO is
enabled &amp;#34;effective&amp;#34; number of rings is 2x what user sees.
So if we are in the bad state, with HW-GRO re-enablement &amp;#34;pending&amp;#34;
after XDP off, and we lower the rings by / 2 - the HW-GRO rings
doing 2x and the ethtool -L doing / 2 may cancel each other out,
and the:&lt;/p&gt;
&lt;p&gt;if (old_rx_rings != bp-&amp;gt;hw_resc.resv_rx_rings &amp;amp;&amp;amp;&lt;/p&gt;
&lt;p&gt;condition in __bnxt_reserve_rings() will be false.
The RSS map won&amp;#39;t get updated, and we&amp;#39;ll crash with:&lt;/p&gt;
&lt;p&gt;BUG: kernel NULL pointer dereference, address: 0000000000000168
  RIP: 0010:__bnxt_hwrm_vni…&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;eth: bnxt: always recalculate features after XDP clearing, fix null-deref&lt;/p&gt;
&lt;p&gt;Recalculate features when XDP is detached.&lt;/p&gt;
&lt;p&gt;Before:
  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
  # ip li set dev eth0 xdp off
  # ethtool -k eth0 | grep gro
  rx-gro-hw: off [requested on]&lt;/p&gt;
&lt;p&gt;After:
  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
  # ip li set dev eth0 xdp off
  # ethtool -k eth0 | grep gro
  rx-gro-hw: on&lt;/p&gt;
&lt;p&gt;The fact that HW-GRO doesn&amp;#39;t get re-enabled automatically is just
a minor annoyance. The real issue is that the features will randomly
come back during another reconfiguration which just happens to invoke
netdev_update_features(). The driver doesn&amp;#39;t handle reconfiguring
two things at a time very robustly.&lt;/p&gt;
&lt;p&gt;Starting with commit 98ba1d931f61 (&amp;#34;bnxt_en: Fix RSS logic in
__bnxt_reserve_rings()&amp;#34;) we only reconfigure the RSS hash table
if the &amp;#34;effective&amp;#34; number of Rx rings has changed. If HW-GRO is
enabled &amp;#34;effective&amp;#34; number of rings is 2x what user sees.
So if we are in the bad state, with HW-GRO re-enablement &amp;#34;pending&amp;#34;
after XDP off, and we lower the rings by / 2 - the HW-GRO rings
doing 2x and the ethtool -L doing / 2 may cancel each other out,
and the:&lt;/p&gt;
&lt;p&gt;if (old_rx_rings != bp-&amp;gt;hw_resc.resv_rx_rings &amp;amp;&amp;amp;&lt;/p&gt;
&lt;p&gt;condition in __bnxt_reserve_rings() will be false.
The RSS map won&amp;#39;t get updated, and we&amp;#39;ll crash with:&lt;/p&gt;
&lt;p&gt;BUG: kernel NULL pointer dereference, address: 0000000000000168
  RIP: 0010:__bnxt_hwrm_vni…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-21682</guid>
    </item>
    <item>
      <title>GHSA-862x-fxfw-xgq9</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-862x-fxfw-xgq9</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;eth: bnxt: always recalculate features after XDP clearing, fix null-deref&lt;/p&gt;
&lt;p&gt;Recalculate features when XDP is detached.&lt;/p&gt;
&lt;p&gt;Before:
  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
  # ip li set dev eth0 xdp off
  # ethtool -k eth0 | grep gro
  rx-gro-hw: off [requested on]&lt;/p&gt;
&lt;p&gt;After:
  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
  # ip li set dev eth0 xdp off
  # ethtool -k eth0 | grep gro
  rx-gro-hw: on&lt;/p&gt;
&lt;p&gt;The fact that HW-GRO doesn&amp;#39;t get re-enabled automatically is just
a minor annoyance. The real issue is that the features will randomly
come back during another reconfiguration which just happens to invoke
netdev_update_features(). The driver doesn&amp;#39;t handle reconfiguring
two things at a time very robustly.&lt;/p&gt;
&lt;p&gt;Starting with commit 98ba1d931f61 (&amp;#34;bnxt_en: Fix RSS logic in
__bnxt_reserve_rings()&amp;#34;) we only reconfigure the RSS hash table
if the &amp;#34;effective&amp;#34; number of Rx rings has changed. If HW-GRO is
enabled &amp;#34;effective&amp;#34; number of rings is 2x what user sees.
So if we are in the bad state, with HW-GRO re-enablement &amp;#34;pending&amp;#34;
after XDP off, and we lower the rings by / 2 - the HW-GRO rings
doing 2x and the ethtool -L doing / 2 may cancel each other out,
and the:&lt;/p&gt;
&lt;p&gt;if (old_rx_rings != bp-&amp;gt;hw_resc.resv_rx_rings &amp;amp;&amp;amp;&lt;/p&gt;
&lt;p&gt;condition in __bnxt_reserve_rings() will be false.
The RSS map won&amp;#39;t get updated, and we&amp;#39;ll crash with:&lt;/p&gt;
&lt;p&gt;BUG: kernel NULL pointer dereference, address: 0000000000000168
  RIP: 0010:__bnxt_hwrm_vni…&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;eth: bnxt: always recalculate features after XDP clearing, fix null-deref&lt;/p&gt;
&lt;p&gt;Recalculate features when XDP is detached.&lt;/p&gt;
&lt;p&gt;Before:
  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
  # ip li set dev eth0 xdp off
  # ethtool -k eth0 | grep gro
  rx-gro-hw: off [requested on]&lt;/p&gt;
&lt;p&gt;After:
  # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp
  # ip li set dev eth0 xdp off
  # ethtool -k eth0 | grep gro
  rx-gro-hw: on&lt;/p&gt;
&lt;p&gt;The fact that HW-GRO doesn&amp;#39;t get re-enabled automatically is just
a minor annoyance. The real issue is that the features will randomly
come back during another reconfiguration which just happens to invoke
netdev_update_features(). The driver doesn&amp;#39;t handle reconfiguring
two things at a time very robustly.&lt;/p&gt;
&lt;p&gt;Starting with commit 98ba1d931f61 (&amp;#34;bnxt_en: Fix RSS logic in
__bnxt_reserve_rings()&amp;#34;) we only reconfigure the RSS hash table
if the &amp;#34;effective&amp;#34; number of Rx rings has changed. If HW-GRO is
enabled &amp;#34;effective&amp;#34; number of rings is 2x what user sees.
So if we are in the bad state, with HW-GRO re-enablement &amp;#34;pending&amp;#34;
after XDP off, and we lower the rings by / 2 - the HW-GRO rings
doing 2x and the ethtool -L doing / 2 may cancel each other out,
and the:&lt;/p&gt;
&lt;p&gt;if (old_rx_rings != bp-&amp;gt;hw_resc.resv_rx_rings &amp;amp;&amp;amp;&lt;/p&gt;
&lt;p&gt;condition in __bnxt_reserve_rings() will be false.
The RSS map won&amp;#39;t get updated, and we&amp;#39;ll crash with:&lt;/p&gt;
&lt;p&gt;BUG: kernel NULL pointer dereference, address: 0000000000000168
  RIP: 0010:__bnxt_hwrm_vni…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-862x-fxfw-xgq9</guid>
    </item>
    <item>
      <title>ICSA-26-209-04 — Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-26-209-04</link>
      <description>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&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.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).&lt;/p&gt;
&lt;p&gt;Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-26-209-04</guid>
    </item>
    <item>
      <title>msrc_CVE-2025-21682 — eth: bnxt: always recalculate features after XDP clearing, fix null-deref</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2025-21682</link>
      <description>msrc_CVE-2025-21682</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2025-21682</guid>
    </item>
    <item>
      <title>OESA-2025-1959 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1959</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:&lt;/p&gt;
&lt;p&gt;xfrm: state: fix out-of-bounds read during lookup&lt;/p&gt;
&lt;p&gt;lookup and resize can run in parallel.&lt;/p&gt;
&lt;p&gt;The xfrm_state_hash_generation seqlock ensures a retry, but the hash
functions can observe a hmask value that is too large for the new hlist
array.&lt;/p&gt;
&lt;p&gt;rehash does:
  rcu_assign_pointer(net-&amp;amp;gt;xfrm.state_bydst, ndst) [..]
  net-&amp;amp;gt;xfrm.state_hmask = nhashmask;&lt;/p&gt;
&lt;p&gt;While state lookup does:
  h = xfrm_dst_hash(net, daddr, saddr, tmpl-&amp;amp;gt;reqid, encap_family);
  hlist_for_each_entry_rcu(x, net-&amp;amp;gt;xfrm.state_bydst + h, bydst) {&lt;/p&gt;
&lt;p&gt;This is only safe in case the update to state_bydst is larger than
net-&amp;amp;gt;xfrm.xfrm_state_hmask (or if the lookup function gets
serialized via state spinlock again).&lt;/p&gt;
&lt;p&gt;Fix this by prefetching state_hmask and the associated pointers.
The xfrm_state_hash_generation seqlock retry will ensure that the pointer
and the hmask will be consistent.&lt;/p&gt;
&lt;p&gt;The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,
add lockdep assertions to document that they are only safe for insert
side.&lt;/p&gt;
&lt;p&gt;xfrm_state_lookup_byaddr() uses the spinlock rather than RCU.
AFAICS this is an oversight from back when state lookup was converted to
RCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;eth: bnxt: always recalculate features after XDP clearing, fix n…&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:&lt;/p&gt;
&lt;p&gt;xfrm: state: fix out-of-bounds read during lookup&lt;/p&gt;
&lt;p&gt;lookup and resize can run in parallel.&lt;/p&gt;
&lt;p&gt;The xfrm_state_hash_generation seqlock ensures a retry, but the hash
functions can observe a hmask value that is too large for the new hlist
array.&lt;/p&gt;
&lt;p&gt;rehash does:
  rcu_assign_pointer(net-&amp;amp;gt;xfrm.state_bydst, ndst) [..]
  net-&amp;amp;gt;xfrm.state_hmask = nhashmask;&lt;/p&gt;
&lt;p&gt;While state lookup does:
  h = xfrm_dst_hash(net, daddr, saddr, tmpl-&amp;amp;gt;reqid, encap_family);
  hlist_for_each_entry_rcu(x, net-&amp;amp;gt;xfrm.state_bydst + h, bydst) {&lt;/p&gt;
&lt;p&gt;This is only safe in case the update to state_bydst is larger than
net-&amp;amp;gt;xfrm.xfrm_state_hmask (or if the lookup function gets
serialized via state spinlock again).&lt;/p&gt;
&lt;p&gt;Fix this by prefetching state_hmask and the associated pointers.
The xfrm_state_hash_generation seqlock retry will ensure that the pointer
and the hmask will be consistent.&lt;/p&gt;
&lt;p&gt;The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,
add lockdep assertions to document that they are only safe for insert
side.&lt;/p&gt;
&lt;p&gt;xfrm_state_lookup_byaddr() uses the spinlock rather than RCU.
AFAICS this is an oversight from back when state lookup was converted to
RCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;eth: bnxt: always recalculate features after XDP clearing, fix n…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1959</guid>
    </item>
    <item>
      <title>SSA-019113 — SSA-019113: Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP V3.1.6</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-019113</link>
      <description>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 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;</description>
      <content:encoded>&lt;p&gt;Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 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;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-019113</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:0428-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:0428-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:0428-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-21682</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21682</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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 171 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: always recalculate features after XDP clearing, fix null-deref Recalculate features when XDP is detached. Before:   # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp   # ip li set dev eth0 xdp off   # ethtool -k eth0 | grep gro   rx-gro-hw: off [requested on] After:   # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp   # ip li set dev eth0 xdp off   # ethtool -k eth0 | grep gro   rx-gro-hw: on The fact that HW-GRO doesn&amp;#39;t get re-enabled automatically is just a minor annoyance. The real issue is that the features will randomly come back during another reconfiguration which just happens to invoke netdev_update_features(). The driver doesn&amp;#39;t handle reconfiguring two things at a time very robustly. Starting with commit 98ba1d931f61 (&amp;#34;bnxt_en: Fix RSS logic in __bnxt_reserve_rings()&amp;#34;) we only reconfigure the RSS hash table if the &amp;#34;effective&amp;#34; number of Rx rings has changed. If HW-GRO is enabled &amp;#34;effective&amp;#34; number of rings is 2x what user sees. So if we are in the bad state, with HW-GRO re-enablement &amp;#34;pending&amp;#34; after XDP off, and we lower the rings by / 2 - the HW-GRO rings doing 2x and the ethtool -L doing / 2 may cancel each other out, and the:   if (old_rx_rings != bp-&amp;gt;hw_resc.resv_rx_rings &amp;amp;&amp;amp; condition in __bnxt_reserve_rings() will be false. The RSS map won&amp;#39;t get updated, and we&amp;#39;ll crash with:   BUG: kernel NULL pointer dereference, address: 0000000000000168   RIP: 0010:__bnxt_hwrm_vnic_set_rss…&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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 171 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: always recalculate features after XDP clearing, fix null-deref Recalculate features when XDP is detached. Before:   # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp   # ip li set dev eth0 xdp off   # ethtool -k eth0 | grep gro   rx-gro-hw: off [requested on] After:   # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp   # ip li set dev eth0 xdp off   # ethtool -k eth0 | grep gro   rx-gro-hw: on The fact that HW-GRO doesn&amp;#39;t get re-enabled automatically is just a minor annoyance. The real issue is that the features will randomly come back during another reconfiguration which just happens to invoke netdev_update_features(). The driver doesn&amp;#39;t handle reconfiguring two things at a time very robustly. Starting with commit 98ba1d931f61 (&amp;#34;bnxt_en: Fix RSS logic in __bnxt_reserve_rings()&amp;#34;) we only reconfigure the RSS hash table if the &amp;#34;effective&amp;#34; number of Rx rings has changed. If HW-GRO is enabled &amp;#34;effective&amp;#34; number of rings is 2x what user sees. So if we are in the bad state, with HW-GRO re-enablement &amp;#34;pending&amp;#34; after XDP off, and we lower the rings by / 2 - the HW-GRO rings doing 2x and the ethtool -L doing / 2 may cancel each other out, and the:   if (old_rx_rings != bp-&amp;gt;hw_resc.resv_rx_rings &amp;amp;&amp;amp; condition in __bnxt_reserve_rings() will be false. The RSS map won&amp;#39;t get updated, and we&amp;#39;ll crash with:   BUG: kernel NULL pointer dereference, address: 0000000000000168   RIP: 0010:__bnxt_hwrm_vnic_set_rss…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21682</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-0232 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0232</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Zustand oder andere, nicht näher beschriebene Auswirkungen zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Zustand oder andere, nicht näher beschriebene Auswirkungen zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0232</guid>
    </item>
  </channel>
</rss>
