<?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:58 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-99057</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-99057</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;xen/netfront: don&amp;#39;t leak the skb when xennet_fill_frags() fails&lt;/p&gt;
&lt;p&gt;When a response chain has more slots than fit in the skb&amp;#39;s frags,
xennet_fill_frags() returns an error and xennet_poll() jumps to its
error path.  That path moves what&amp;#39;s left on tmpq to errq to be freed,
but the skb being filled was already dequeued from tmpq, so it&amp;#39;s never
freed.  Each chain that overflows leaks the skb and the pages attached
to it as frags, and the backend decides how many slots it sends.&lt;/p&gt;
&lt;p&gt;Put the skb back on tmpq before taking the error path, like the
xennet_set_skb_gso() failure just above it does.&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;xen/netfront: don&amp;#39;t leak the skb when xennet_fill_frags() fails&lt;/p&gt;
&lt;p&gt;When a response chain has more slots than fit in the skb&amp;#39;s frags,
xennet_fill_frags() returns an error and xennet_poll() jumps to its
error path.  That path moves what&amp;#39;s left on tmpq to errq to be freed,
but the skb being filled was already dequeued from tmpq, so it&amp;#39;s never
freed.  Each chain that overflows leaks the skb and the pages attached
to it as frags, and the backend decides how many slots it sends.&lt;/p&gt;
&lt;p&gt;Put the skb back on tmpq before taking the error path, like the
xennet_set_skb_gso() failure just above it does.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-99057</guid>
    </item>
    <item>
      <title>GHSA-32c4-hc77-g5cm</title>
      <link>https://db.gcve.eu/vuln/ghsa-32c4-hc77-g5cm</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;xen/netfront: don&amp;#39;t leak the skb when xennet_fill_frags() fails&lt;/p&gt;
&lt;p&gt;When a response chain has more slots than fit in the skb&amp;#39;s frags,
xennet_fill_frags() returns an error and xennet_poll() jumps to its
error path.  That path moves what&amp;#39;s left on tmpq to errq to be freed,
but the skb being filled was already dequeued from tmpq, so it&amp;#39;s never
freed.  Each chain that overflows leaks the skb and the pages attached
to it as frags, and the backend decides how many slots it sends.&lt;/p&gt;
&lt;p&gt;Put the skb back on tmpq before taking the error path, like the
xennet_set_skb_gso() failure just above it does.&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;xen/netfront: don&amp;#39;t leak the skb when xennet_fill_frags() fails&lt;/p&gt;
&lt;p&gt;When a response chain has more slots than fit in the skb&amp;#39;s frags,
xennet_fill_frags() returns an error and xennet_poll() jumps to its
error path.  That path moves what&amp;#39;s left on tmpq to errq to be freed,
but the skb being filled was already dequeued from tmpq, so it&amp;#39;s never
freed.  Each chain that overflows leaks the skb and the pages attached
to it as frags, and the backend decides how many slots it sends.&lt;/p&gt;
&lt;p&gt;Put the skb back on tmpq before taking the error path, like the
xennet_set_skb_gso() failure just above it does.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-32c4-hc77-g5cm</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-99057 — xen/netfront: don't leak the skb when xennet_fill_frags() fails</title>
      <link>https://db.gcve.eu/vuln/msrc_cve-2026-99057</link>
      <description>msrc_CVE-2026-99057</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/msrc_cve-2026-99057</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-99057</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-99057</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 253 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: xen/netfront: don&amp;#39;t leak the skb when xennet_fill_frags() fails When a response chain has more slots than fit in the skb&amp;#39;s frags, xennet_fill_frags() returns an error and xennet_poll() jumps to its error path.  That path moves what&amp;#39;s left on tmpq to errq to be freed, but the skb being filled was already dequeued from tmpq, so it&amp;#39;s never freed.  Each chain that overflows leaks the skb and the pages attached to it as frags, and the backend decides how many slots it sends. Put the skb back on tmpq before taking the error path, like the xennet_set_skb_gso() failure just above it does.&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 253 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: xen/netfront: don&amp;#39;t leak the skb when xennet_fill_frags() fails When a response chain has more slots than fit in the skb&amp;#39;s frags, xennet_fill_frags() returns an error and xennet_poll() jumps to its error path.  That path moves what&amp;#39;s left on tmpq to errq to be freed, but the skb being filled was already dequeued from tmpq, so it&amp;#39;s never freed.  Each chain that overflows leaks the skb and the pages attached to it as frags, and the backend decides how many slots it sends. Put the skb back on tmpq before taking the error path, like the xennet_set_skb_gso() failure just above it does.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-99057</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-4152 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://db.gcve.eu/vuln/wid-sec-w-2026-4152</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/wid-sec-w-2026-4152</guid>
    </item>
  </channel>
</rss>
