<?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>Mon, 05 Oct 2026 02:14:18 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-97563 — smb: client: reject out-of-bounds DataOffset in CIFSSMBRead()</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2026-97563</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&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;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&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/cve-2026-97563</guid>
    </item>
  </channel>
</rss>
