<?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>Sun, 04 Oct 2026 11:36:28 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-31538</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-31538</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-31538</guid>
    </item>
    <item>
      <title>EUVD-2026-347711</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-347711</link>
      <description>EUVD-2026-347711</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-347711</guid>
    </item>
    <item>
      <title>fkie_cve-2026-31538</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-31538</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: server: make use of smbdirect_socket.recv_io.credits.available&lt;/p&gt;
&lt;p&gt;The logic off managing recv credits by counting posted recv_io and
granted credits is racy.&lt;/p&gt;
&lt;p&gt;That&amp;#39;s because the peer might already consumed a credit,
but between receiving the incoming recv at the hardware
and processing the completion in the &amp;#39;recv_done&amp;#39; functions
we likely have a window where we grant credits, which
don&amp;#39;t really exist.&lt;/p&gt;
&lt;p&gt;So we better have a decicated counter for the
available credits, which will be incremented
when we posted new recv buffers and drained when
we grant the credits to the peer.&lt;/p&gt;
&lt;p&gt;This fixes regression Namjae reported with
the 6.18 release.&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;smb: server: make use of smbdirect_socket.recv_io.credits.available&lt;/p&gt;
&lt;p&gt;The logic off managing recv credits by counting posted recv_io and
granted credits is racy.&lt;/p&gt;
&lt;p&gt;That&amp;#39;s because the peer might already consumed a credit,
but between receiving the incoming recv at the hardware
and processing the completion in the &amp;#39;recv_done&amp;#39; functions
we likely have a window where we grant credits, which
don&amp;#39;t really exist.&lt;/p&gt;
&lt;p&gt;So we better have a decicated counter for the
available credits, which will be incremented
when we posted new recv buffers and drained when
we grant the credits to the peer.&lt;/p&gt;
&lt;p&gt;This fixes regression Namjae reported with
the 6.18 release.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-31538</guid>
    </item>
    <item>
      <title>GHSA-f5hg-hrh7-wfrr</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-f5hg-hrh7-wfrr</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: server: make use of smbdirect_socket.recv_io.credits.available&lt;/p&gt;
&lt;p&gt;The logic off managing recv credits by counting posted recv_io and
granted credits is racy.&lt;/p&gt;
&lt;p&gt;That&amp;#39;s because the peer might already consumed a credit,
but between receiving the incoming recv at the hardware
and processing the completion in the &amp;#39;recv_done&amp;#39; functions
we likely have a window where we grant credits, which
don&amp;#39;t really exist.&lt;/p&gt;
&lt;p&gt;So we better have a decicated counter for the
available credits, which will be incremented
when we posted new recv buffers and drained when
we grant the credits to the peer.&lt;/p&gt;
&lt;p&gt;This fixes regression Namjae reported with
the 6.18 release.&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;smb: server: make use of smbdirect_socket.recv_io.credits.available&lt;/p&gt;
&lt;p&gt;The logic off managing recv credits by counting posted recv_io and
granted credits is racy.&lt;/p&gt;
&lt;p&gt;That&amp;#39;s because the peer might already consumed a credit,
but between receiving the incoming recv at the hardware
and processing the completion in the &amp;#39;recv_done&amp;#39; functions
we likely have a window where we grant credits, which
don&amp;#39;t really exist.&lt;/p&gt;
&lt;p&gt;So we better have a decicated counter for the
available credits, which will be incremented
when we posted new recv buffers and drained when
we grant the credits to the peer.&lt;/p&gt;
&lt;p&gt;This fixes regression Namjae reported with
the 6.18 release.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-f5hg-hrh7-wfrr</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-31538</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31538</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 85 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: smb: server: make use of smbdirect_socket.recv_io.credits.available The logic off managing recv credits by counting posted recv_io and granted credits is racy. That&amp;#39;s because the peer might already consumed a credit, but between receiving the incoming recv at the hardware and processing the completion in the &amp;#39;recv_done&amp;#39; functions we likely have a window where we grant credits, which don&amp;#39;t really exist. So we better have a decicated counter for the available credits, which will be incremented when we posted new recv buffers and drained when we grant the credits to the peer. This fixes regression Namjae reported with the 6.18 release.&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 85 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: smb: server: make use of smbdirect_socket.recv_io.credits.available The logic off managing recv credits by counting posted recv_io and granted credits is racy. That&amp;#39;s because the peer might already consumed a credit, but between receiving the incoming recv at the hardware and processing the completion in the &amp;#39;recv_done&amp;#39; functions we likely have a window where we grant credits, which don&amp;#39;t really exist. So we better have a decicated counter for the available credits, which will be incremented when we posted new recv buffers and drained when we grant the credits to the peer. This fixes regression Namjae reported with the 6.18 release.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31538</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1279 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1279</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, welche zu einem Denial-of-Service-Zustand, einer Rechteausweitung, der Ausführung von Code oder einer Speicherbeschädigung führen könnten.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, welche zu einem Denial-of-Service-Zustand, einer Rechteausweitung, der Ausführung von Code oder einer Speicherbeschädigung führen könnten.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1279</guid>
    </item>
  </channel>
</rss>
