<?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://vulnerability.circl.lu</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>Thu, 01 Oct 2026 15:30:41 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-72381 — ksmbd: fix use-after-free of fp-&gt;owner.name in durable handle owner check</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-72381</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: fix use-after-free of fp-&amp;gt;owner.name in durable handle owner check&lt;/p&gt;
&lt;p&gt;Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same
persistent_id race the fp-&amp;gt;owner.name compare-read in
ksmbd_vfs_compare_durable_owner() against the kfree() in
ksmbd_reopen_durable_fd()&amp;#39;s reopen-success path. fp-&amp;gt;owner.name is a
standalone kstrdup() buffer whose lifetime is independent of the fp
refcount, and the two sites share no lock: the compare reads the buffer
while the reopen frees it, so the strcmp() can dereference freed memory.&lt;/p&gt;
&lt;p&gt;Commit 7ce4fc40018d (&amp;#34;ksmbd: fix durable reconnect double-bind race in
ksmbd_reopen_durable_fd&amp;#34;) made the fp-&amp;gt;conn claim atomic under
global_ft.lock (closing the owner.name double-free and the ksmbd_file
write-UAF), but the compare-read versus reopen-free pair was left
unserialized.&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80
  Read of size 1 by task kworker
    strcmp
    ksmbd_vfs_compare_durable_owner
    smb2_check_durable_oplock
    smb2_open
  Freed by task kworker:
    kfree
    ksmbd_reopen_durable_fd
    smb2_open
  Allocated by task kworker:
    kstrdup
    session_fd_check
    smb2_session_logoff
  The buggy address belongs to the cache kmalloc-8&lt;/p&gt;
&lt;p&gt;Serialize both sides of the race with fp-&amp;gt;f_lock.  The global durable
file-table lock still protects the durable reconnect claim, but
fp-&amp;gt;owner.name is per-open state and does not need to block unrelated
durable table lo…&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: fix use-after-free of fp-&amp;gt;owner.name in durable handle owner check&lt;/p&gt;
&lt;p&gt;Two concurrent SMB2 durable reconnects (DH2C/DHnC) on the same
persistent_id race the fp-&amp;gt;owner.name compare-read in
ksmbd_vfs_compare_durable_owner() against the kfree() in
ksmbd_reopen_durable_fd()&amp;#39;s reopen-success path. fp-&amp;gt;owner.name is a
standalone kstrdup() buffer whose lifetime is independent of the fp
refcount, and the two sites share no lock: the compare reads the buffer
while the reopen frees it, so the strcmp() can dereference freed memory.&lt;/p&gt;
&lt;p&gt;Commit 7ce4fc40018d (&amp;#34;ksmbd: fix durable reconnect double-bind race in
ksmbd_reopen_durable_fd&amp;#34;) made the fp-&amp;gt;conn claim atomic under
global_ft.lock (closing the owner.name double-free and the ksmbd_file
write-UAF), but the compare-read versus reopen-free pair was left
unserialized.&lt;/p&gt;
&lt;p&gt;BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x80
  Read of size 1 by task kworker
    strcmp
    ksmbd_vfs_compare_durable_owner
    smb2_check_durable_oplock
    smb2_open
  Freed by task kworker:
    kfree
    ksmbd_reopen_durable_fd
    smb2_open
  Allocated by task kworker:
    kstrdup
    session_fd_check
    smb2_session_logoff
  The buggy address belongs to the cache kmalloc-8&lt;/p&gt;
&lt;p&gt;Serialize both sides of the race with fp-&amp;gt;f_lock.  The global durable
file-table lock still protects the durable reconnect claim, but
fp-&amp;gt;owner.name is per-open state and does not need to block unrelated
durable table lo…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-72381</guid>
    </item>
  </channel>
</rss>
