<?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 23:47:42 +0000</lastBuildDate>
    <item>
      <title>CVE-2023-53854 — ASoC: mediatek: mt8186: Fix use-after-free in driver remove path</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2023-53854</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;ASoC: mediatek: mt8186: Fix use-after-free in driver remove path&lt;/p&gt;
&lt;p&gt;When devm runs function in the &amp;#34;remove&amp;#34; path for a device it runs them
in the reverse order. That means that if you have parts of your driver
that aren&amp;#39;t using devm or are using &amp;#34;roll your own&amp;#34; devm w/
devm_add_action_or_reset() you need to keep that in mind.&lt;/p&gt;
&lt;p&gt;The mt8186 audio driver didn&amp;#39;t quite get this right. Specifically, in
mt8186_init_clock() it called mt8186_audsys_clk_register() and then
went on to call a bunch of other devm function. The caller of
mt8186_init_clock() used devm_add_action_or_reset() to call
mt8186_deinit_clock() but, because of the intervening devm functions,
the order was wrong.&lt;/p&gt;
&lt;p&gt;Specifically at probe time, the order was:
1. mt8186_audsys_clk_register()
2. afe_priv-&amp;gt;clk = devm_kcalloc(...)
3. afe_priv-&amp;gt;clk[i] = devm_clk_get(...)&lt;/p&gt;
&lt;p&gt;At remove time, the order (which should have been 3, 2, 1) was:
1. mt8186_audsys_clk_unregister()
3. Free all of afe_priv-&amp;gt;clk[i]
2. Free afe_priv-&amp;gt;clk&lt;/p&gt;
&lt;p&gt;The above seemed to be causing a use-after-free. Luckily, it&amp;#39;s easy to
fix this by simply using devm more correctly. Let&amp;#39;s move the
devm_add_action_or_reset() to the right place. In addition to fixing
the use-after-free, code inspection shows that this fixes a leak
(missing call to mt8186_audsys_clk_unregister()) that would have
happened if any of the syscon_regmap_lookup_by_phandle() calls in
mt8186_init_clock() had failed.&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;ASoC: mediatek: mt8186: Fix use-after-free in driver remove path&lt;/p&gt;
&lt;p&gt;When devm runs function in the &amp;#34;remove&amp;#34; path for a device it runs them
in the reverse order. That means that if you have parts of your driver
that aren&amp;#39;t using devm or are using &amp;#34;roll your own&amp;#34; devm w/
devm_add_action_or_reset() you need to keep that in mind.&lt;/p&gt;
&lt;p&gt;The mt8186 audio driver didn&amp;#39;t quite get this right. Specifically, in
mt8186_init_clock() it called mt8186_audsys_clk_register() and then
went on to call a bunch of other devm function. The caller of
mt8186_init_clock() used devm_add_action_or_reset() to call
mt8186_deinit_clock() but, because of the intervening devm functions,
the order was wrong.&lt;/p&gt;
&lt;p&gt;Specifically at probe time, the order was:
1. mt8186_audsys_clk_register()
2. afe_priv-&amp;gt;clk = devm_kcalloc(...)
3. afe_priv-&amp;gt;clk[i] = devm_clk_get(...)&lt;/p&gt;
&lt;p&gt;At remove time, the order (which should have been 3, 2, 1) was:
1. mt8186_audsys_clk_unregister()
3. Free all of afe_priv-&amp;gt;clk[i]
2. Free afe_priv-&amp;gt;clk&lt;/p&gt;
&lt;p&gt;The above seemed to be causing a use-after-free. Luckily, it&amp;#39;s easy to
fix this by simply using devm more correctly. Let&amp;#39;s move the
devm_add_action_or_reset() to the right place. In addition to fixing
the use-after-free, code inspection shows that this fixes a leak
(missing call to mt8186_audsys_clk_unregister()) that would have
happened if any of the syscon_regmap_lookup_by_phandle() calls in
mt8186_init_clock() had failed.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2023-53854</guid>
    </item>
  </channel>
</rss>
