<?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 19:31:36 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-97563</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-97563</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-97563</guid>
    </item>
    <item>
      <title>EUVD-2026-375596</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-375596</link>
      <description>EUVD-2026-375596</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-375596</guid>
    </item>
    <item>
      <title>fkie_cve-2026-97563</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-97563</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: reject out-of-bounds DataOffset in CIFSSMBRead()&lt;/p&gt;
&lt;p&gt;The SMB1 synchronous read helper CIFSSMBRead() validates the server&amp;#39;s
DataLength against CIFSMaxBufSize and the caller&amp;#39;s count, but never
validates DataOffset. The copy source is formed as&lt;/p&gt;
&lt;p&gt;&amp;amp;pSMBr-&amp;gt;hdr.Protocol + le16_to_cpu(pSMBr-&amp;gt;DataOffset)&lt;/p&gt;
&lt;p&gt;and memcpy()&amp;#39;d for DataLength bytes with no check that the
[DataOffset, DataOffset + DataLength) range lies within the response
actually received from the server.&lt;/p&gt;
&lt;p&gt;A malicious or compromised SMB1 server can return a response carrying
an in-range DataLength and a large DataOffset, driving the source
pointer past the end of the response buffer. The memcpy() then copies
adjacent kernel heap into the caller&amp;#39;s read buffer (information
disclosure), or reads unmapped memory and oopses (denial of service).
SMB1 is not negotiated by default; reaching this code requires an
explicit vers=1.0 mount.&lt;/p&gt;
&lt;p&gt;Both DataOffset and the received response length recorded in
rsp_iov.iov_len are relative to the start of the SMB header, so reject
the response unless DataOffset + DataLength fits within that length,
using overflow-safe arithmetic, before forming the source pointer.
The response length has been validated by the previous patch, so the
DataOffset and DataLength fields can be read safely here.&lt;/p&gt;
&lt;p&gt;While here, make data_length unsigned. It holds a length derived from
unsigned on-the-wire fields and is only ever compared again…&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: client: reject out-of-bounds DataOffset in CIFSSMBRead()&lt;/p&gt;
&lt;p&gt;The SMB1 synchronous read helper CIFSSMBRead() validates the server&amp;#39;s
DataLength against CIFSMaxBufSize and the caller&amp;#39;s count, but never
validates DataOffset. The copy source is formed as&lt;/p&gt;
&lt;p&gt;&amp;amp;pSMBr-&amp;gt;hdr.Protocol + le16_to_cpu(pSMBr-&amp;gt;DataOffset)&lt;/p&gt;
&lt;p&gt;and memcpy()&amp;#39;d for DataLength bytes with no check that the
[DataOffset, DataOffset + DataLength) range lies within the response
actually received from the server.&lt;/p&gt;
&lt;p&gt;A malicious or compromised SMB1 server can return a response carrying
an in-range DataLength and a large DataOffset, driving the source
pointer past the end of the response buffer. The memcpy() then copies
adjacent kernel heap into the caller&amp;#39;s read buffer (information
disclosure), or reads unmapped memory and oopses (denial of service).
SMB1 is not negotiated by default; reaching this code requires an
explicit vers=1.0 mount.&lt;/p&gt;
&lt;p&gt;Both DataOffset and the received response length recorded in
rsp_iov.iov_len are relative to the start of the SMB header, so reject
the response unless DataOffset + DataLength fits within that length,
using overflow-safe arithmetic, before forming the source pointer.
The response length has been validated by the previous patch, so the
DataOffset and DataLength fields can be read safely here.&lt;/p&gt;
&lt;p&gt;While here, make data_length unsigned. It holds a length derived from
unsigned on-the-wire fields and is only ever compared again…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-97563</guid>
    </item>
    <item>
      <title>GHSA-wp4g-rrmp-2p82</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-wp4g-rrmp-2p82</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: reject out-of-bounds DataOffset in CIFSSMBRead()&lt;/p&gt;
&lt;p&gt;The SMB1 synchronous read helper CIFSSMBRead() validates the server&amp;#39;s
DataLength against CIFSMaxBufSize and the caller&amp;#39;s count, but never
validates DataOffset. The copy source is formed as&lt;/p&gt;
&lt;p&gt;&amp;amp;pSMBr-&amp;gt;hdr.Protocol + le16_to_cpu(pSMBr-&amp;gt;DataOffset)&lt;/p&gt;
&lt;p&gt;and memcpy()&amp;#39;d for DataLength bytes with no check that the
[DataOffset, DataOffset + DataLength) range lies within the response
actually received from the server.&lt;/p&gt;
&lt;p&gt;A malicious or compromised SMB1 server can return a response carrying
an in-range DataLength and a large DataOffset, driving the source
pointer past the end of the response buffer. The memcpy() then copies
adjacent kernel heap into the caller&amp;#39;s read buffer (information
disclosure), or reads unmapped memory and oopses (denial of service).
SMB1 is not negotiated by default; reaching this code requires an
explicit vers=1.0 mount.&lt;/p&gt;
&lt;p&gt;Both DataOffset and the received response length recorded in
rsp_iov.iov_len are relative to the start of the SMB header, so reject
the response unless DataOffset + DataLength fits within that length,
using overflow-safe arithmetic, before forming the source pointer.
The response length has been validated by the previous patch, so the
DataOffset and DataLength fields can be read safely here.&lt;/p&gt;
&lt;p&gt;While here, make data_length unsigned. It holds a length derived from
unsigned on-the-wire fields and is only ever compared again…&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: client: reject out-of-bounds DataOffset in CIFSSMBRead()&lt;/p&gt;
&lt;p&gt;The SMB1 synchronous read helper CIFSSMBRead() validates the server&amp;#39;s
DataLength against CIFSMaxBufSize and the caller&amp;#39;s count, but never
validates DataOffset. The copy source is formed as&lt;/p&gt;
&lt;p&gt;&amp;amp;pSMBr-&amp;gt;hdr.Protocol + le16_to_cpu(pSMBr-&amp;gt;DataOffset)&lt;/p&gt;
&lt;p&gt;and memcpy()&amp;#39;d for DataLength bytes with no check that the
[DataOffset, DataOffset + DataLength) range lies within the response
actually received from the server.&lt;/p&gt;
&lt;p&gt;A malicious or compromised SMB1 server can return a response carrying
an in-range DataLength and a large DataOffset, driving the source
pointer past the end of the response buffer. The memcpy() then copies
adjacent kernel heap into the caller&amp;#39;s read buffer (information
disclosure), or reads unmapped memory and oopses (denial of service).
SMB1 is not negotiated by default; reaching this code requires an
explicit vers=1.0 mount.&lt;/p&gt;
&lt;p&gt;Both DataOffset and the received response length recorded in
rsp_iov.iov_len are relative to the start of the SMB header, so reject
the response unless DataOffset + DataLength fits within that length,
using overflow-safe arithmetic, before forming the source pointer.
The response length has been validated by the previous patch, so the
DataOffset and DataLength fields can be read safely here.&lt;/p&gt;
&lt;p&gt;While here, make data_length unsigned. It holds a length derived from
unsigned on-the-wire fields and is only ever compared again…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-wp4g-rrmp-2p82</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-97563 — smb: client: reject out-of-bounds DataOffset in CIFSSMBRead()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-97563</link>
      <description>msrc_CVE-2026-97563</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-97563</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-97563</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-97563</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, 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 and 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: smb: client: reject out-of-bounds DataOffset in CIFSSMBRead() The SMB1 synchronous read helper CIFSSMBRead() validates the server&amp;#39;s DataLength against CIFSMaxBufSize and the caller&amp;#39;s count, but never validates DataOffset. The copy source is formed as 	&amp;amp;pSMBr-&amp;gt;hdr.Protocol + le16_to_cpu(pSMBr-&amp;gt;DataOffset) and memcpy()&amp;#39;d for DataLength bytes with no check that the [DataOffset, DataOffset + DataLength) range lies within the response actually received from the server. A malicious or compromised SMB1 server can return a response carrying an in-range DataLength and a large DataOffset, driving the source pointer past the end of the response buffer. The memcpy() then copies adjacent kernel heap into the caller&amp;#39;s read buffer (information disclosure), or reads unmapped memory and oopses (denial of service). SMB1 is not negotiated by default; reaching this code requires an explicit vers=1.0 mount. Both DataOffset and the received response length recorded in rsp_iov.iov_len are relative to the start of the SMB header, so reject the response unless DataOffset + DataLength fits within that length, using overflow-safe arithmetic, before forming the source pointer. The response length has been validated by the previous patch, so the DataOffset and DataLength fields can be read safely here. While here, make data_length unsigned. It holds a length derived from unsigned on-the-wire fields and is only ever compared against unsi…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, 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 and 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: smb: client: reject out-of-bounds DataOffset in CIFSSMBRead() The SMB1 synchronous read helper CIFSSMBRead() validates the server&amp;#39;s DataLength against CIFSMaxBufSize and the caller&amp;#39;s count, but never validates DataOffset. The copy source is formed as 	&amp;amp;pSMBr-&amp;gt;hdr.Protocol + le16_to_cpu(pSMBr-&amp;gt;DataOffset) and memcpy()&amp;#39;d for DataLength bytes with no check that the [DataOffset, DataOffset + DataLength) range lies within the response actually received from the server. A malicious or compromised SMB1 server can return a response carrying an in-range DataLength and a large DataOffset, driving the source pointer past the end of the response buffer. The memcpy() then copies adjacent kernel heap into the caller&amp;#39;s read buffer (information disclosure), or reads unmapped memory and oopses (denial of service). SMB1 is not negotiated by default; reaching this code requires an explicit vers=1.0 mount. Both DataOffset and the received response length recorded in rsp_iov.iov_len are relative to the start of the SMB header, so reject the response unless DataOffset + DataLength fits within that length, using overflow-safe arithmetic, before forming the source pointer. The response length has been validated by the previous patch, so the DataOffset and DataLength fields can be read safely here. While here, make data_length unsigned. It holds a length derived from unsigned on-the-wire fields and is only ever compared against unsi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-97563</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3579 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3579</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen oder nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3579</guid>
    </item>
  </channel>
</rss>
