CVE-2023-53854

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8186: Fix use-after-free in driver remove path<br /> <br /> When devm runs function in the "remove" path for a device it runs them<br /> in the reverse order. That means that if you have parts of your driver<br /> that aren&amp;#39;t using devm or are using "roll your own" devm w/<br /> devm_add_action_or_reset() you need to keep that in mind.<br /> <br /> The mt8186 audio driver didn&amp;#39;t quite get this right. Specifically, in<br /> mt8186_init_clock() it called mt8186_audsys_clk_register() and then<br /> went on to call a bunch of other devm function. The caller of<br /> mt8186_init_clock() used devm_add_action_or_reset() to call<br /> mt8186_deinit_clock() but, because of the intervening devm functions,<br /> the order was wrong.<br /> <br /> Specifically at probe time, the order was:<br /> 1. mt8186_audsys_clk_register()<br /> 2. afe_priv-&gt;clk = devm_kcalloc(...)<br /> 3. afe_priv-&gt;clk[i] = devm_clk_get(...)<br /> <br /> At remove time, the order (which should have been 3, 2, 1) was:<br /> 1. mt8186_audsys_clk_unregister()<br /> 3. Free all of afe_priv-&gt;clk[i]<br /> 2. Free afe_priv-&gt;clk<br /> <br /> The above seemed to be causing a use-after-free. Luckily, it&amp;#39;s easy to<br /> fix this by simply using devm more correctly. Let&amp;#39;s move the<br /> devm_add_action_or_reset() to the right place. In addition to fixing<br /> the use-after-free, code inspection shows that this fixes a leak<br /> (missing call to mt8186_audsys_clk_unregister()) that would have<br /> happened if any of the syscon_regmap_lookup_by_phandle() calls in<br /> mt8186_init_clock() had failed.