<?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>Tue, 03 Nov 2026 14:43:22 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-98616</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-98616</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;eth: fbnic: reset num_napi when the napi vectors are freed&lt;/p&gt;
&lt;p&gt;fbn-&amp;gt;num_napi is the count of live napi vectors, each of which owns an
IRQ.  The PM path had freed them without clearing the count.
fbnic_pm_suspend() tears the datapath down via ndo_stop() and frees the
IRQs, but leaves netif_running() true so resume knows to re-open.  Resume
rebuilds the datapath in __fbnic_pm_resume() and fbnic_reset_queues() sets
num_napi and __fbnic_open() re-allocates the vectors.&lt;/p&gt;
&lt;p&gt;When the datapath is torn down but never rebuilt, num_napi is left
pointing at freed vectors under 2 different scenarios:
 - a PCIe error recovery that fails (fbnic_err_slot_reset() -&amp;gt;
   __fbnic_pm_resume() returns an error -&amp;gt; PCI_ERS_RESULT_DISCONNECT), so
   .resume never runs; or
 - an __fbnic_open() that fails partway on resume and unwinds, freeing
   the vectors after fbnic_reset_queues() has already set num_napi.&lt;/p&gt;
&lt;p&gt;The netdev is then running with num_napi &amp;gt; 0 but napi[] freed, and the
eventual remove/unbind close re-enters fbnic_down() -&amp;gt; fbnic_dbg_down()
and dereferences the freed vectors:
  BUG: kernel NULL pointer dereference, address: 0000000000000210
  RIP: fbnic_dbg_down+0x28&lt;/p&gt;
&lt;p&gt;Clear num_napi when the vectors are freed: in the suspend teardown (a
good resume re-establishes it before __fbnic_open()) and on the resume
open failure.  A redundant ndo_stop() then walks an empty napi[].  The
normal ndo_stop() down/up cycle is untouched and kee…&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: fbnic: reset num_napi when the napi vectors are freed&lt;/p&gt;
&lt;p&gt;fbn-&amp;gt;num_napi is the count of live napi vectors, each of which owns an
IRQ.  The PM path had freed them without clearing the count.
fbnic_pm_suspend() tears the datapath down via ndo_stop() and frees the
IRQs, but leaves netif_running() true so resume knows to re-open.  Resume
rebuilds the datapath in __fbnic_pm_resume() and fbnic_reset_queues() sets
num_napi and __fbnic_open() re-allocates the vectors.&lt;/p&gt;
&lt;p&gt;When the datapath is torn down but never rebuilt, num_napi is left
pointing at freed vectors under 2 different scenarios:
 - a PCIe error recovery that fails (fbnic_err_slot_reset() -&amp;gt;
   __fbnic_pm_resume() returns an error -&amp;gt; PCI_ERS_RESULT_DISCONNECT), so
   .resume never runs; or
 - an __fbnic_open() that fails partway on resume and unwinds, freeing
   the vectors after fbnic_reset_queues() has already set num_napi.&lt;/p&gt;
&lt;p&gt;The netdev is then running with num_napi &amp;gt; 0 but napi[] freed, and the
eventual remove/unbind close re-enters fbnic_down() -&amp;gt; fbnic_dbg_down()
and dereferences the freed vectors:
  BUG: kernel NULL pointer dereference, address: 0000000000000210
  RIP: fbnic_dbg_down+0x28&lt;/p&gt;
&lt;p&gt;Clear num_napi when the vectors are freed: in the suspend teardown (a
good resume re-establishes it before __fbnic_open()) and on the resume
open failure.  A redundant ndo_stop() then walks an empty napi[].  The
normal ndo_stop() down/up cycle is untouched and kee…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-98616</guid>
    </item>
    <item>
      <title>GHSA-mr3q-wfmx-4w6m</title>
      <link>https://db.gcve.eu/vuln/ghsa-mr3q-wfmx-4w6m</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;eth: fbnic: reset num_napi when the napi vectors are freed&lt;/p&gt;
&lt;p&gt;fbn-&amp;gt;num_napi is the count of live napi vectors, each of which owns an
IRQ.  The PM path had freed them without clearing the count.
fbnic_pm_suspend() tears the datapath down via ndo_stop() and frees the
IRQs, but leaves netif_running() true so resume knows to re-open.  Resume
rebuilds the datapath in __fbnic_pm_resume() and fbnic_reset_queues() sets
num_napi and __fbnic_open() re-allocates the vectors.&lt;/p&gt;
&lt;p&gt;When the datapath is torn down but never rebuilt, num_napi is left
pointing at freed vectors under 2 different scenarios:
 - a PCIe error recovery that fails (fbnic_err_slot_reset() -&amp;gt;
   __fbnic_pm_resume() returns an error -&amp;gt; PCI_ERS_RESULT_DISCONNECT), so
   .resume never runs; or
 - an __fbnic_open() that fails partway on resume and unwinds, freeing
   the vectors after fbnic_reset_queues() has already set num_napi.&lt;/p&gt;
&lt;p&gt;The netdev is then running with num_napi &amp;gt; 0 but napi[] freed, and the
eventual remove/unbind close re-enters fbnic_down() -&amp;gt; fbnic_dbg_down()
and dereferences the freed vectors:
  BUG: kernel NULL pointer dereference, address: 0000000000000210
  RIP: fbnic_dbg_down+0x28&lt;/p&gt;
&lt;p&gt;Clear num_napi when the vectors are freed: in the suspend teardown (a
good resume re-establishes it before __fbnic_open()) and on the resume
open failure.  A redundant ndo_stop() then walks an empty napi[].  The
normal ndo_stop() down/up cycle is untouched and kee…&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: fbnic: reset num_napi when the napi vectors are freed&lt;/p&gt;
&lt;p&gt;fbn-&amp;gt;num_napi is the count of live napi vectors, each of which owns an
IRQ.  The PM path had freed them without clearing the count.
fbnic_pm_suspend() tears the datapath down via ndo_stop() and frees the
IRQs, but leaves netif_running() true so resume knows to re-open.  Resume
rebuilds the datapath in __fbnic_pm_resume() and fbnic_reset_queues() sets
num_napi and __fbnic_open() re-allocates the vectors.&lt;/p&gt;
&lt;p&gt;When the datapath is torn down but never rebuilt, num_napi is left
pointing at freed vectors under 2 different scenarios:
 - a PCIe error recovery that fails (fbnic_err_slot_reset() -&amp;gt;
   __fbnic_pm_resume() returns an error -&amp;gt; PCI_ERS_RESULT_DISCONNECT), so
   .resume never runs; or
 - an __fbnic_open() that fails partway on resume and unwinds, freeing
   the vectors after fbnic_reset_queues() has already set num_napi.&lt;/p&gt;
&lt;p&gt;The netdev is then running with num_napi &amp;gt; 0 but napi[] freed, and the
eventual remove/unbind close re-enters fbnic_down() -&amp;gt; fbnic_dbg_down()
and dereferences the freed vectors:
  BUG: kernel NULL pointer dereference, address: 0000000000000210
  RIP: fbnic_dbg_down+0x28&lt;/p&gt;
&lt;p&gt;Clear num_napi when the vectors are freed: in the suspend teardown (a
good resume re-establishes it before __fbnic_open()) and on the resume
open failure.  A redundant ndo_stop() then walks an empty napi[].  The
normal ndo_stop() down/up cycle is untouched and kee…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-mr3q-wfmx-4w6m</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-98616 — eth: fbnic: reset num_napi when the napi vectors are freed</title>
      <link>https://db.gcve.eu/vuln/msrc_cve-2026-98616</link>
      <description>msrc_CVE-2026-98616</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/msrc_cve-2026-98616</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-98616</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-98616</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 120 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: reset num_napi when the napi vectors are freed fbn-&amp;gt;num_napi is the count of live napi vectors, each of which owns an IRQ.  The PM path had freed them without clearing the count. fbnic_pm_suspend() tears the datapath down via ndo_stop() and frees the IRQs, but leaves netif_running() true so resume knows to re-open.  Resume rebuilds the datapath in __fbnic_pm_resume() and fbnic_reset_queues() sets num_napi and __fbnic_open() re-allocates the vectors. When the datapath is torn down but never rebuilt, num_napi is left pointing at freed vectors under 2 different scenarios:  - a PCIe error recovery that fails (fbnic_err_slot_reset() -&amp;gt;    __fbnic_pm_resume() returns an error -&amp;gt; PCI_ERS_RESULT_DISCONNECT), so    .resume never runs; or  - an __fbnic_open() that fails partway on resume and unwinds, freeing    the vectors after fbnic_reset_queues() has already set num_napi. The netdev is then running with num_napi &amp;gt; 0 but napi[] freed, and the eventual remove/unbind close re-enters fbnic_down() -&amp;gt; fbnic_dbg_down() and dereferences the freed vectors:   BUG: kernel NULL pointer dereference, address: 0000000000000210   RIP: fbnic_dbg_down+0x28 Clear num_napi when the vectors are freed: in the suspend teardown (a good resume re-establishes it before __fbnic_open()) and on the resume open failure.  A redundant ndo_stop() then walks an empty napi[].  The normal ndo_stop() down/up cycle is untouched and keeps nu…&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 120 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: reset num_napi when the napi vectors are freed fbn-&amp;gt;num_napi is the count of live napi vectors, each of which owns an IRQ.  The PM path had freed them without clearing the count. fbnic_pm_suspend() tears the datapath down via ndo_stop() and frees the IRQs, but leaves netif_running() true so resume knows to re-open.  Resume rebuilds the datapath in __fbnic_pm_resume() and fbnic_reset_queues() sets num_napi and __fbnic_open() re-allocates the vectors. When the datapath is torn down but never rebuilt, num_napi is left pointing at freed vectors under 2 different scenarios:  - a PCIe error recovery that fails (fbnic_err_slot_reset() -&amp;gt;    __fbnic_pm_resume() returns an error -&amp;gt; PCI_ERS_RESULT_DISCONNECT), so    .resume never runs; or  - an __fbnic_open() that fails partway on resume and unwinds, freeing    the vectors after fbnic_reset_queues() has already set num_napi. The netdev is then running with num_napi &amp;gt; 0 but napi[] freed, and the eventual remove/unbind close re-enters fbnic_down() -&amp;gt; fbnic_dbg_down() and dereferences the freed vectors:   BUG: kernel NULL pointer dereference, address: 0000000000000210   RIP: fbnic_dbg_down+0x28 Clear num_napi when the vectors are freed: in the suspend teardown (a good resume re-establishes it before __fbnic_open()) and on the resume open failure.  A redundant ndo_stop() then walks an empty napi[].  The normal ndo_stop() down/up cycle is untouched and keeps nu…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-98616</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-4019 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://db.gcve.eu/vuln/wid-sec-w-2026-4019</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-4019</guid>
    </item>
  </channel>
</rss>
