<?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://db.gcve.eu</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>Mon, 09 Nov 2026 17:24:47 +0000</lastBuildDate>
    <item>
      <title>certfr-2026-avi-1375 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Certaines d'entre elles permettent à…</title>
      <link>https://db.gcve.eu/vuln/certfr-2026-avi-1375</link>
      <description>certfr-2026-avi-1375</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/certfr-2026-avi-1375</guid>
    </item>
    <item>
      <title>fkie_cve-2026-98490</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-98490</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: openvswitch: conntrack: fix helper UAF due to extensions realloc&lt;/p&gt;
&lt;p&gt;While calling the helpers, a raw pointer to the extensions area is
wired into expectations list:&lt;/p&gt;
&lt;p&gt;-&amp;gt; nf_ct_helper()
   -&amp;gt; helper-&amp;gt;help()
    -&amp;gt; nf_ct_expect_related_report()
     -&amp;gt; nf_ct_expect_insert()
      -&amp;gt; hlist_add_head_rcu(&amp;amp;exp-&amp;gt;lnode, &amp;amp;master_help-&amp;gt;expectations)&lt;/p&gt;
&lt;p&gt;In case the connection is not confirmed yet, more extensions can be
added afterwards with *_ext_add() calls reallocating the extension
space and leaving the now invalid pointer in the expectations list
that is later accessed while removing the expectation.&lt;/p&gt;
&lt;p&gt;Make sure that helpers are called at the end after all the other
extensions are already added.&lt;/p&gt;
&lt;p&gt;Note that the helper rejection now leaves the mark and labels set,
but that&amp;#39;s not different from how the NAT was handled before or how
the mark and the labels were handled on confirmation failure.  And
there are no atomicity guarantees provided by the API anyway.&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: openvswitch: conntrack: fix helper UAF due to extensions realloc&lt;/p&gt;
&lt;p&gt;While calling the helpers, a raw pointer to the extensions area is
wired into expectations list:&lt;/p&gt;
&lt;p&gt;-&amp;gt; nf_ct_helper()
   -&amp;gt; helper-&amp;gt;help()
    -&amp;gt; nf_ct_expect_related_report()
     -&amp;gt; nf_ct_expect_insert()
      -&amp;gt; hlist_add_head_rcu(&amp;amp;exp-&amp;gt;lnode, &amp;amp;master_help-&amp;gt;expectations)&lt;/p&gt;
&lt;p&gt;In case the connection is not confirmed yet, more extensions can be
added afterwards with *_ext_add() calls reallocating the extension
space and leaving the now invalid pointer in the expectations list
that is later accessed while removing the expectation.&lt;/p&gt;
&lt;p&gt;Make sure that helpers are called at the end after all the other
extensions are already added.&lt;/p&gt;
&lt;p&gt;Note that the helper rejection now leaves the mark and labels set,
but that&amp;#39;s not different from how the NAT was handled before or how
the mark and the labels were handled on confirmation failure.  And
there are no atomicity guarantees provided by the API anyway.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-98490</guid>
    </item>
    <item>
      <title>GHSA-4r7h-j2g8-7vfx</title>
      <link>https://db.gcve.eu/vuln/ghsa-4r7h-j2g8-7vfx</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: openvswitch: conntrack: fix helper UAF due to extensions realloc&lt;/p&gt;
&lt;p&gt;While calling the helpers, a raw pointer to the extensions area is
wired into expectations list:&lt;/p&gt;
&lt;p&gt;-&amp;gt; nf_ct_helper()
   -&amp;gt; helper-&amp;gt;help()
    -&amp;gt; nf_ct_expect_related_report()
     -&amp;gt; nf_ct_expect_insert()
      -&amp;gt; hlist_add_head_rcu(&amp;amp;exp-&amp;gt;lnode, &amp;amp;master_help-&amp;gt;expectations)&lt;/p&gt;
&lt;p&gt;In case the connection is not confirmed yet, more extensions can be
added afterwards with *_ext_add() calls reallocating the extension
space and leaving the now invalid pointer in the expectations list
that is later accessed while removing the expectation.&lt;/p&gt;
&lt;p&gt;Make sure that helpers are called at the end after all the other
extensions are already added.&lt;/p&gt;
&lt;p&gt;Note that the helper rejection now leaves the mark and labels set,
but that&amp;#39;s not different from how the NAT was handled before or how
the mark and the labels were handled on confirmation failure.  And
there are no atomicity guarantees provided by the API anyway.&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: openvswitch: conntrack: fix helper UAF due to extensions realloc&lt;/p&gt;
&lt;p&gt;While calling the helpers, a raw pointer to the extensions area is
wired into expectations list:&lt;/p&gt;
&lt;p&gt;-&amp;gt; nf_ct_helper()
   -&amp;gt; helper-&amp;gt;help()
    -&amp;gt; nf_ct_expect_related_report()
     -&amp;gt; nf_ct_expect_insert()
      -&amp;gt; hlist_add_head_rcu(&amp;amp;exp-&amp;gt;lnode, &amp;amp;master_help-&amp;gt;expectations)&lt;/p&gt;
&lt;p&gt;In case the connection is not confirmed yet, more extensions can be
added afterwards with *_ext_add() calls reallocating the extension
space and leaving the now invalid pointer in the expectations list
that is later accessed while removing the expectation.&lt;/p&gt;
&lt;p&gt;Make sure that helpers are called at the end after all the other
extensions are already added.&lt;/p&gt;
&lt;p&gt;Note that the helper rejection now leaves the mark and labels set,
but that&amp;#39;s not different from how the NAT was handled before or how
the mark and the labels were handled on confirmation failure.  And
there are no atomicity guarantees provided by the API anyway.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-4r7h-j2g8-7vfx</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-98490 — net: openvswitch: conntrack: fix helper UAF due to extensions realloc</title>
      <link>https://db.gcve.eu/vuln/msrc_cve-2026-98490</link>
      <description>msrc_CVE-2026-98490</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/msrc_cve-2026-98490</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-98490</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-98490</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 247 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: conntrack: fix helper UAF due to extensions realloc While calling the helpers, a raw pointer to the extensions area is wired into expectations list:   -&amp;gt; nf_ct_helper()    -&amp;gt; helper-&amp;gt;help()     -&amp;gt; nf_ct_expect_related_report()      -&amp;gt; nf_ct_expect_insert()       -&amp;gt; hlist_add_head_rcu(&amp;amp;exp-&amp;gt;lnode, &amp;amp;master_help-&amp;gt;expectations) In case the connection is not confirmed yet, more extensions can be added afterwards with *_ext_add() calls reallocating the extension space and leaving the now invalid pointer in the expectations list that is later accessed while removing the expectation. Make sure that helpers are called at the end after all the other extensions are already added. Note that the helper rejection now leaves the mark and labels set, but that&amp;#39;s not different from how the NAT was handled before or how the mark and the labels were handled on confirmation failure.  And there are no atomicity guarantees provided by the API anyway.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 247 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: conntrack: fix helper UAF due to extensions realloc While calling the helpers, a raw pointer to the extensions area is wired into expectations list:   -&amp;gt; nf_ct_helper()    -&amp;gt; helper-&amp;gt;help()     -&amp;gt; nf_ct_expect_related_report()      -&amp;gt; nf_ct_expect_insert()       -&amp;gt; hlist_add_head_rcu(&amp;amp;exp-&amp;gt;lnode, &amp;amp;master_help-&amp;gt;expectations) In case the connection is not confirmed yet, more extensions can be added afterwards with *_ext_add() calls reallocating the extension space and leaving the now invalid pointer in the expectations list that is later accessed while removing the expectation. Make sure that helpers are called at the end after all the other extensions are already added. Note that the helper rejection now leaves the mark and labels set, but that&amp;#39;s not different from how the NAT was handled before or how the mark and the labels were handled on confirmation failure.  And there are no atomicity guarantees provided by the API anyway.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-98490</guid>
    </item>
  </channel>
</rss>
