<?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 20:54:48 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-45977</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-45977</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-45977</guid>
    </item>
    <item>
      <title>EUVD-2026-321873</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-321873</link>
      <description>EUVD-2026-321873</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-321873</guid>
    </item>
    <item>
      <title>fkie_cve-2026-45977</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-45977</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fbnic: close fw_log race between users and teardown&lt;/p&gt;
&lt;p&gt;Fixes a theoretical race on fw_log between the teardown path and fw_log
write functions.&lt;/p&gt;
&lt;p&gt;fw_log is written inside fbnic_fw_log_write() and can be reached from
the mailbox handler fbnic_fw_msix_intr(), but fw_log is freed before
IRQ/MBX teardown during cleanup, resulting in a potential data race of
dereferencing a freed/null variable.&lt;/p&gt;
&lt;p&gt;Possible Interleaving Scenario:
  CPU0: fbnic_fw_msix_intr() // Entry
          fbnic_fw_log_write()
            if (fbnic_fw_log_ready())   // true
            ... preempt ...
  CPU1: fbnic_remove() // Entry
          fbnic_fw_log_free()
            vfree(log-&amp;gt;data_start);
            log-&amp;gt;data_start = NULL;
  CPU0: continues, walks log-&amp;gt;entries or writes to log-&amp;gt;data_start&lt;/p&gt;
&lt;p&gt;The initialization also has an incorrect order problem, as the fw_log
is currently allocated after MBX setup during initialization.
Fix the problems by adjusting the synchronization order to put
initialization in place before the mailbox is enabled, and not cleared
until after the mailbox has been disabled.&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;fbnic: close fw_log race between users and teardown&lt;/p&gt;
&lt;p&gt;Fixes a theoretical race on fw_log between the teardown path and fw_log
write functions.&lt;/p&gt;
&lt;p&gt;fw_log is written inside fbnic_fw_log_write() and can be reached from
the mailbox handler fbnic_fw_msix_intr(), but fw_log is freed before
IRQ/MBX teardown during cleanup, resulting in a potential data race of
dereferencing a freed/null variable.&lt;/p&gt;
&lt;p&gt;Possible Interleaving Scenario:
  CPU0: fbnic_fw_msix_intr() // Entry
          fbnic_fw_log_write()
            if (fbnic_fw_log_ready())   // true
            ... preempt ...
  CPU1: fbnic_remove() // Entry
          fbnic_fw_log_free()
            vfree(log-&amp;gt;data_start);
            log-&amp;gt;data_start = NULL;
  CPU0: continues, walks log-&amp;gt;entries or writes to log-&amp;gt;data_start&lt;/p&gt;
&lt;p&gt;The initialization also has an incorrect order problem, as the fw_log
is currently allocated after MBX setup during initialization.
Fix the problems by adjusting the synchronization order to put
initialization in place before the mailbox is enabled, and not cleared
until after the mailbox has been disabled.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-45977</guid>
    </item>
    <item>
      <title>GHSA-fgxx-jh4j-vgpg</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-fgxx-jh4j-vgpg</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;fbnic: close fw_log race between users and teardown&lt;/p&gt;
&lt;p&gt;Fixes a theoretical race on fw_log between the teardown path and fw_log
write functions.&lt;/p&gt;
&lt;p&gt;fw_log is written inside fbnic_fw_log_write() and can be reached from
the mailbox handler fbnic_fw_msix_intr(), but fw_log is freed before
IRQ/MBX teardown during cleanup, resulting in a potential data race of
dereferencing a freed/null variable.&lt;/p&gt;
&lt;p&gt;Possible Interleaving Scenario:
  CPU0: fbnic_fw_msix_intr() // Entry
          fbnic_fw_log_write()
            if (fbnic_fw_log_ready())   // true
            ... preempt ...
  CPU1: fbnic_remove() // Entry
          fbnic_fw_log_free()
            vfree(log-&amp;gt;data_start);
            log-&amp;gt;data_start = NULL;
  CPU0: continues, walks log-&amp;gt;entries or writes to log-&amp;gt;data_start&lt;/p&gt;
&lt;p&gt;The initialization also has an incorrect order problem, as the fw_log
is currently allocated after MBX setup during initialization.
Fix the problems by adjusting the synchronization order to put
initialization in place before the mailbox is enabled, and not cleared
until after the mailbox has been disabled.&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;fbnic: close fw_log race between users and teardown&lt;/p&gt;
&lt;p&gt;Fixes a theoretical race on fw_log between the teardown path and fw_log
write functions.&lt;/p&gt;
&lt;p&gt;fw_log is written inside fbnic_fw_log_write() and can be reached from
the mailbox handler fbnic_fw_msix_intr(), but fw_log is freed before
IRQ/MBX teardown during cleanup, resulting in a potential data race of
dereferencing a freed/null variable.&lt;/p&gt;
&lt;p&gt;Possible Interleaving Scenario:
  CPU0: fbnic_fw_msix_intr() // Entry
          fbnic_fw_log_write()
            if (fbnic_fw_log_ready())   // true
            ... preempt ...
  CPU1: fbnic_remove() // Entry
          fbnic_fw_log_free()
            vfree(log-&amp;gt;data_start);
            log-&amp;gt;data_start = NULL;
  CPU0: continues, walks log-&amp;gt;entries or writes to log-&amp;gt;data_start&lt;/p&gt;
&lt;p&gt;The initialization also has an incorrect order problem, as the fw_log
is currently allocated after MBX setup during initialization.
Fix the problems by adjusting the synchronization order to put
initialization in place before the mailbox is enabled, and not cleared
until after the mailbox has been disabled.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-fgxx-jh4j-vgpg</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-45977</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45977</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 103 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: fbnic: close fw_log race between users and teardown Fixes a theoretical race on fw_log between the teardown path and fw_log write functions. fw_log is written inside fbnic_fw_log_write() and can be reached from the mailbox handler fbnic_fw_msix_intr(), but fw_log is freed before IRQ/MBX teardown during cleanup, resulting in a potential data race of dereferencing a freed/null variable. Possible Interleaving Scenario:   CPU0: fbnic_fw_msix_intr() // Entry           fbnic_fw_log_write()             if (fbnic_fw_log_ready())   // true             ... preempt ...   CPU1: fbnic_remove() // Entry           fbnic_fw_log_free()             vfree(log-&amp;gt;data_start);             log-&amp;gt;data_start = NULL;   CPU0: continues, walks log-&amp;gt;entries or writes to log-&amp;gt;data_start The initialization also has an incorrect order problem, as the fw_log is currently allocated after MBX setup during initialization. Fix the problems by adjusting the synchronization order to put initialization in place before the mailbox is enabled, and not cleared until after the mailbox has been disabled.&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 103 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: fbnic: close fw_log race between users and teardown Fixes a theoretical race on fw_log between the teardown path and fw_log write functions. fw_log is written inside fbnic_fw_log_write() and can be reached from the mailbox handler fbnic_fw_msix_intr(), but fw_log is freed before IRQ/MBX teardown during cleanup, resulting in a potential data race of dereferencing a freed/null variable. Possible Interleaving Scenario:   CPU0: fbnic_fw_msix_intr() // Entry           fbnic_fw_log_write()             if (fbnic_fw_log_ready())   // true             ... preempt ...   CPU1: fbnic_remove() // Entry           fbnic_fw_log_free()             vfree(log-&amp;gt;data_start);             log-&amp;gt;data_start = NULL;   CPU0: continues, walks log-&amp;gt;entries or writes to log-&amp;gt;data_start The initialization also has an incorrect order problem, as the fw_log is currently allocated after MBX setup during initialization. Fix the problems by adjusting the synchronization order to put initialization in place before the mailbox is enabled, and not cleared until after the mailbox has been disabled.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45977</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1700 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700</guid>
    </item>
  </channel>
</rss>
