<?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>Fri, 30 Oct 2026 02:49:14 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-99113 — ksmbd: zero the FS_OBJECT_ID_INFORMATION buffer before filling it in</title>
      <link>https://db.gcve.eu/vuln/cve-2026-99113</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;ksmbd: zero the FS_OBJECT_ID_INFORMATION buffer before filling it in&lt;/p&gt;
&lt;p&gt;smb2_get_info_filesystem() reports 64 bytes for FS_OBJECT_ID_INFORMATION,
that is the whole of struct object_id_info, but writes only 46 of them:&lt;/p&gt;
&lt;p&gt;- objid[] is 16 bytes, and when the volume UUID is not available only
   sizeof(stfs.f_fsid) (8) bytes are copied into it;
 - extended_info.version_string[] is STRING_LENGTH (28) bytes, and only
   strlen(&amp;#34;1.1.0&amp;#34;) (5) bytes are copied into it.&lt;/p&gt;
&lt;p&gt;The response buffer is zeroed on allocation (kvzalloc() in
smb2_allocate_rsp_buf()), so for a standalone request the remaining 31
bytes are zero.  In a compound request they need not be.  The offset of
the next response is advanced by the length pinned for the previous one,
so if a preceding command wrote its reply into the buffer and then
failed, smb2_set_err_rsp() pins only the short error response and the
next reply lands inside the area that has already been written.  Only
the header is cleared there:&lt;/p&gt;
&lt;p&gt;memset((char *)rsp_hdr, 0, sizeof(struct smb2_hdr) + 2);&lt;/p&gt;
&lt;p&gt;The client then receives up to 31 bytes of a response it was not meant
to see, including one that failed with an access denied error.&lt;/p&gt;
&lt;p&gt;Clear the structure before filling it in.  As a side effect
version_string is now NUL terminated.&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;ksmbd: zero the FS_OBJECT_ID_INFORMATION buffer before filling it in&lt;/p&gt;
&lt;p&gt;smb2_get_info_filesystem() reports 64 bytes for FS_OBJECT_ID_INFORMATION,
that is the whole of struct object_id_info, but writes only 46 of them:&lt;/p&gt;
&lt;p&gt;- objid[] is 16 bytes, and when the volume UUID is not available only
   sizeof(stfs.f_fsid) (8) bytes are copied into it;
 - extended_info.version_string[] is STRING_LENGTH (28) bytes, and only
   strlen(&amp;#34;1.1.0&amp;#34;) (5) bytes are copied into it.&lt;/p&gt;
&lt;p&gt;The response buffer is zeroed on allocation (kvzalloc() in
smb2_allocate_rsp_buf()), so for a standalone request the remaining 31
bytes are zero.  In a compound request they need not be.  The offset of
the next response is advanced by the length pinned for the previous one,
so if a preceding command wrote its reply into the buffer and then
failed, smb2_set_err_rsp() pins only the short error response and the
next reply lands inside the area that has already been written.  Only
the header is cleared there:&lt;/p&gt;
&lt;p&gt;memset((char *)rsp_hdr, 0, sizeof(struct smb2_hdr) + 2);&lt;/p&gt;
&lt;p&gt;The client then receives up to 31 bytes of a response it was not meant
to see, including one that failed with an access denied error.&lt;/p&gt;
&lt;p&gt;Clear the structure before filling it in.  As a side effect
version_string is now NUL terminated.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-99113</guid>
    </item>
  </channel>
</rss>
