<?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>Tue, 29 Sep 2026 06:26:06 +0000</lastBuildDate>
    <item>
      <title>CVE-2023-53276 — ubifs: Free memory for tmpfile name</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2023-53276</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;ubifs: Free memory for tmpfile name&lt;/p&gt;
&lt;p&gt;When opening a ubifs tmpfile on an encrypted directory, function
fscrypt_setup_filename allocates memory for the name that is to be
stored in the directory entry, but after the name has been copied to the
directory entry inode, the memory is not freed.&lt;/p&gt;
&lt;p&gt;When running kmemleak on it we see that it is registered as a leak. The
report below is triggered by a simple program &amp;#39;tmpfile&amp;#39; just opening a
tmpfile:&lt;/p&gt;
&lt;p&gt;unreferenced object 0xffff88810178f380 (size 32):
    comm &amp;#34;tmpfile&amp;#34;, pid 509, jiffies 4294934744 (age 1524.742s)
    backtrace:
      __kmem_cache_alloc_node
      __kmalloc
      fscrypt_setup_filename
      ubifs_tmpfile
      vfs_tmpfile
      path_openat&lt;/p&gt;
&lt;p&gt;Free this memory after it has been copied to the inode.&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;ubifs: Free memory for tmpfile name&lt;/p&gt;
&lt;p&gt;When opening a ubifs tmpfile on an encrypted directory, function
fscrypt_setup_filename allocates memory for the name that is to be
stored in the directory entry, but after the name has been copied to the
directory entry inode, the memory is not freed.&lt;/p&gt;
&lt;p&gt;When running kmemleak on it we see that it is registered as a leak. The
report below is triggered by a simple program &amp;#39;tmpfile&amp;#39; just opening a
tmpfile:&lt;/p&gt;
&lt;p&gt;unreferenced object 0xffff88810178f380 (size 32):
    comm &amp;#34;tmpfile&amp;#34;, pid 509, jiffies 4294934744 (age 1524.742s)
    backtrace:
      __kmem_cache_alloc_node
      __kmalloc
      fscrypt_setup_filename
      ubifs_tmpfile
      vfs_tmpfile
      path_openat&lt;/p&gt;
&lt;p&gt;Free this memory after it has been copied to the inode.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2023-53276</guid>
    </item>
  </channel>
</rss>
