<?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 17:44:48 +0000</lastBuildDate>
    <item>
      <title>Withdrawn: BELL-CVE-2026-72407 — CVE-2026-72407 does not affect BellSoft software</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-72407</link>
      <description>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-72407</guid>
    </item>
    <item>
      <title>EUVD-2026-354074</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-354074</link>
      <description>EUVD-2026-354074</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-354074</guid>
    </item>
    <item>
      <title>fkie_cve-2026-72407</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-72407</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;geneve: validate inner network offset in geneve_gro_complete()&lt;/p&gt;
&lt;p&gt;Even with both paths gated on gs-&amp;gt;gro_hint, geneve_gro_complete()
re-derives the inner dispatch type and length from the packet and the
current gs-&amp;gt;gro_hint, independently of geneve_gro_receive(). The two can
disagree if gs-&amp;gt;gro_hint flips under a concurrent geneve_quiesce()/
geneve_unquiesce() (sk_user_data is NULL across a synchronize_net()), or if
the re-read option bytes differ from the ones receive parsed.&lt;/p&gt;
&lt;p&gt;geneve_gro_receive() already records the inner network header position in
NAPI_GRO_CB()-&amp;gt;inner_network_offset. Have geneve_gro_complete() compute the
offset it is about to dispatch at, adding ETH_HLEN in the ETH_P_TEB case
where eth_gro_complete() steps over the inner MAC header, and bail out if
it lands past inner_network_offset.&lt;/p&gt;
&lt;p&gt;Use a lower bound rather than exact equality: between gh_len and the inner
L3 header, geneve_gro_receive() may also have pulled an inner VLAN tag
(vlan_gro_receive() advances the recorded offset past it), which only moves
inner_network_offset further out. A valid frame therefore always satisfies
inner_nh &amp;lt;= inner_network_offset, while a gh_len inflated by a hint
gro_receive() did not honour dispatches past the validated inner header,
i.e. the out-of-bounds completion. Only the latter is rejected.&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;geneve: validate inner network offset in geneve_gro_complete()&lt;/p&gt;
&lt;p&gt;Even with both paths gated on gs-&amp;gt;gro_hint, geneve_gro_complete()
re-derives the inner dispatch type and length from the packet and the
current gs-&amp;gt;gro_hint, independently of geneve_gro_receive(). The two can
disagree if gs-&amp;gt;gro_hint flips under a concurrent geneve_quiesce()/
geneve_unquiesce() (sk_user_data is NULL across a synchronize_net()), or if
the re-read option bytes differ from the ones receive parsed.&lt;/p&gt;
&lt;p&gt;geneve_gro_receive() already records the inner network header position in
NAPI_GRO_CB()-&amp;gt;inner_network_offset. Have geneve_gro_complete() compute the
offset it is about to dispatch at, adding ETH_HLEN in the ETH_P_TEB case
where eth_gro_complete() steps over the inner MAC header, and bail out if
it lands past inner_network_offset.&lt;/p&gt;
&lt;p&gt;Use a lower bound rather than exact equality: between gh_len and the inner
L3 header, geneve_gro_receive() may also have pulled an inner VLAN tag
(vlan_gro_receive() advances the recorded offset past it), which only moves
inner_network_offset further out. A valid frame therefore always satisfies
inner_nh &amp;lt;= inner_network_offset, while a gh_len inflated by a hint
gro_receive() did not honour dispatches past the validated inner header,
i.e. the out-of-bounds completion. Only the latter is rejected.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-72407</guid>
    </item>
    <item>
      <title>GHSA-gp9v-9c23-fw32</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gp9v-9c23-fw32</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;geneve: validate inner network offset in geneve_gro_complete()&lt;/p&gt;
&lt;p&gt;Even with both paths gated on gs-&amp;gt;gro_hint, geneve_gro_complete()
re-derives the inner dispatch type and length from the packet and the
current gs-&amp;gt;gro_hint, independently of geneve_gro_receive(). The two can
disagree if gs-&amp;gt;gro_hint flips under a concurrent geneve_quiesce()/
geneve_unquiesce() (sk_user_data is NULL across a synchronize_net()), or if
the re-read option bytes differ from the ones receive parsed.&lt;/p&gt;
&lt;p&gt;geneve_gro_receive() already records the inner network header position in
NAPI_GRO_CB()-&amp;gt;inner_network_offset. Have geneve_gro_complete() compute the
offset it is about to dispatch at, adding ETH_HLEN in the ETH_P_TEB case
where eth_gro_complete() steps over the inner MAC header, and bail out if
it lands past inner_network_offset.&lt;/p&gt;
&lt;p&gt;Use a lower bound rather than exact equality: between gh_len and the inner
L3 header, geneve_gro_receive() may also have pulled an inner VLAN tag
(vlan_gro_receive() advances the recorded offset past it), which only moves
inner_network_offset further out. A valid frame therefore always satisfies
inner_nh &amp;lt;= inner_network_offset, while a gh_len inflated by a hint
gro_receive() did not honour dispatches past the validated inner header,
i.e. the out-of-bounds completion. Only the latter is rejected.&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;geneve: validate inner network offset in geneve_gro_complete()&lt;/p&gt;
&lt;p&gt;Even with both paths gated on gs-&amp;gt;gro_hint, geneve_gro_complete()
re-derives the inner dispatch type and length from the packet and the
current gs-&amp;gt;gro_hint, independently of geneve_gro_receive(). The two can
disagree if gs-&amp;gt;gro_hint flips under a concurrent geneve_quiesce()/
geneve_unquiesce() (sk_user_data is NULL across a synchronize_net()), or if
the re-read option bytes differ from the ones receive parsed.&lt;/p&gt;
&lt;p&gt;geneve_gro_receive() already records the inner network header position in
NAPI_GRO_CB()-&amp;gt;inner_network_offset. Have geneve_gro_complete() compute the
offset it is about to dispatch at, adding ETH_HLEN in the ETH_P_TEB case
where eth_gro_complete() steps over the inner MAC header, and bail out if
it lands past inner_network_offset.&lt;/p&gt;
&lt;p&gt;Use a lower bound rather than exact equality: between gh_len and the inner
L3 header, geneve_gro_receive() may also have pulled an inner VLAN tag
(vlan_gro_receive() advances the recorded offset past it), which only moves
inner_network_offset further out. A valid frame therefore always satisfies
inner_nh &amp;lt;= inner_network_offset, while a gh_len inflated by a hint
gro_receive() did not honour dispatches past the validated inner header,
i.e. the out-of-bounds completion. Only the latter is rejected.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gp9v-9c23-fw32</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-72407</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72407</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 115 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: geneve: validate inner network offset in geneve_gro_complete() Even with both paths gated on gs-&amp;gt;gro_hint, geneve_gro_complete() re-derives the inner dispatch type and length from the packet and the current gs-&amp;gt;gro_hint, independently of geneve_gro_receive(). The two can disagree if gs-&amp;gt;gro_hint flips under a concurrent geneve_quiesce()/ geneve_unquiesce() (sk_user_data is NULL across a synchronize_net()), or if the re-read option bytes differ from the ones receive parsed. geneve_gro_receive() already records the inner network header position in NAPI_GRO_CB()-&amp;gt;inner_network_offset. Have geneve_gro_complete() compute the offset it is about to dispatch at, adding ETH_HLEN in the ETH_P_TEB case where eth_gro_complete() steps over the inner MAC header, and bail out if it lands past inner_network_offset. Use a lower bound rather than exact equality: between gh_len and the inner L3 header, geneve_gro_receive() may also have pulled an inner VLAN tag (vlan_gro_receive() advances the recorded offset past it), which only moves inner_network_offset further out. A valid frame therefore always satisfies inner_nh &amp;lt;= inner_network_offset, while a gh_len inflated by a hint gro_receive() did not honour dispatches past the validated inner header, i.e. the out-of-bounds completion. Only the latter is rejected.&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 115 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: geneve: validate inner network offset in geneve_gro_complete() Even with both paths gated on gs-&amp;gt;gro_hint, geneve_gro_complete() re-derives the inner dispatch type and length from the packet and the current gs-&amp;gt;gro_hint, independently of geneve_gro_receive(). The two can disagree if gs-&amp;gt;gro_hint flips under a concurrent geneve_quiesce()/ geneve_unquiesce() (sk_user_data is NULL across a synchronize_net()), or if the re-read option bytes differ from the ones receive parsed. geneve_gro_receive() already records the inner network header position in NAPI_GRO_CB()-&amp;gt;inner_network_offset. Have geneve_gro_complete() compute the offset it is about to dispatch at, adding ETH_HLEN in the ETH_P_TEB case where eth_gro_complete() steps over the inner MAC header, and bail out if it lands past inner_network_offset. Use a lower bound rather than exact equality: between gh_len and the inner L3 header, geneve_gro_receive() may also have pulled an inner VLAN tag (vlan_gro_receive() advances the recorded offset past it), which only moves inner_network_offset further out. A valid frame therefore always satisfies inner_nh &amp;lt;= inner_network_offset, while a gh_len inflated by a hint gro_receive() did not honour dispatches past the validated inner header, i.e. the out-of-bounds completion. Only the latter is rejected.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-72407</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2852 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852</guid>
    </item>
  </channel>
</rss>
