<?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>Wed, 30 Sep 2026 02:55:18 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-68416 — mtd: fix double free and WARN_ON in add_mtd_device() error paths</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-68416</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;mtd: fix double free and WARN_ON in add_mtd_device() error paths&lt;/p&gt;
&lt;p&gt;When device_register() or mtd_nvmem_add() fails inside
add_mtd_device() for a partition, the error handling triggers
mtd_release() via put_device() or device_unregister(). mtd_release()
calls release_mtd_partition() which frees the mtd_info structure.
However, callers such as mtd_add_partition() and add_mtd_partitions()
also call free_partition() in their error paths, resulting in a double
free.&lt;/p&gt;
&lt;p&gt;Additionally, release_mtd_partition() hits WARN_ON(!list_empty(
&amp;amp;mtd-&amp;gt;part.node)) because the partition node is still linked in the
parent&amp;#39;s partitions list when the release callback fires from the
add_mtd_device() error path.&lt;/p&gt;
&lt;p&gt;Fix this by overriding dev-&amp;gt;type and dev-&amp;gt;release before put_device()
in the error paths, so that device_release() invokes a no-op function
instead of mtd_release(). For the mtd_nvmem_add() failure case,
device_unregister() is replaced with device_del() to separate the
device removal from the final kobject reference drop, allowing the
override to take effect before put_device() is called.&lt;/p&gt;
&lt;p&gt;The callers&amp;#39; error paths (list_del + free_partition) remain the sole
owners of mtd_info lifetime on add_mtd_device() failure, which is the
expected contract.&lt;/p&gt;
&lt;p&gt;The normal partition teardown path is not affected: del_mtd_device()
goes through kref_put() -&amp;gt; mtd_device_release() -&amp;gt; device_unregister()
with dev-&amp;gt;type still set to &amp;amp;mtd_devtype, so…&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;mtd: fix double free and WARN_ON in add_mtd_device() error paths&lt;/p&gt;
&lt;p&gt;When device_register() or mtd_nvmem_add() fails inside
add_mtd_device() for a partition, the error handling triggers
mtd_release() via put_device() or device_unregister(). mtd_release()
calls release_mtd_partition() which frees the mtd_info structure.
However, callers such as mtd_add_partition() and add_mtd_partitions()
also call free_partition() in their error paths, resulting in a double
free.&lt;/p&gt;
&lt;p&gt;Additionally, release_mtd_partition() hits WARN_ON(!list_empty(
&amp;amp;mtd-&amp;gt;part.node)) because the partition node is still linked in the
parent&amp;#39;s partitions list when the release callback fires from the
add_mtd_device() error path.&lt;/p&gt;
&lt;p&gt;Fix this by overriding dev-&amp;gt;type and dev-&amp;gt;release before put_device()
in the error paths, so that device_release() invokes a no-op function
instead of mtd_release(). For the mtd_nvmem_add() failure case,
device_unregister() is replaced with device_del() to separate the
device removal from the final kobject reference drop, allowing the
override to take effect before put_device() is called.&lt;/p&gt;
&lt;p&gt;The callers&amp;#39; error paths (list_del + free_partition) remain the sole
owners of mtd_info lifetime on add_mtd_device() failure, which is the
expected contract.&lt;/p&gt;
&lt;p&gt;The normal partition teardown path is not affected: del_mtd_device()
goes through kref_put() -&amp;gt; mtd_device_release() -&amp;gt; device_unregister()
with dev-&amp;gt;type still set to &amp;amp;mtd_devtype, so…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-68416</guid>
    </item>
  </channel>
</rss>
