VYPR
Unrated severityNVD Advisory· Published Dec 9, 2025· Updated Apr 15, 2026

CVE-2023-53854

CVE-2023-53854

Description

In the Linux kernel, the following vulnerability has been resolved:

ASoC: mediatek: mt8186: Fix use-after-free in driver remove path

When devm runs function in the "remove" path for a device it runs them in the reverse order. That means that if you have parts of your driver that aren't using devm or are using "roll your own" devm w/ devm_add_action_or_reset() you need to keep that in mind.

The mt8186 audio driver didn'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.

Specifically at probe time, the order was: 1. mt8186_audsys_clk_register() 2. afe_priv->clk = devm_kcalloc(...) 3. afe_priv->clk[i] = devm_clk_get(...)

At remove time, the order (which should have been 3, 2, 1) was: 1. mt8186_audsys_clk_unregister() 3. Free all of afe_priv->clk[i] 2. Free afe_priv->clk

The above seemed to be causing a use-after-free. Luckily, it's easy to fix this by simply using devm more correctly. Let'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.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

A use-after-free vulnerability in the Linux kernel's Mediatek MT8186 audio driver due to incorrect devm resource ordering in the remove path.

Vulnerability

Overview

In the Linux kernel, a use-after-free vulnerability was found in the Mediatek MT8186 ASoC audio driver. The root cause is an incorrect ordering of resource cleanup in the driver's remove path. The driver used devm_add_action_or_reset() to register a cleanup function for clock deinitialization, but due to the way devm resources are freed in reverse order, the clock unregister function ran before other devm-managed resources (like clock pointers) were freed, leading to a use-after-free condition [1].

Exploitation

This vulnerability is triggered during driver removal, which occurs when the device is unbound or the module is removed. An attacker would need to have the ability to trigger device removal, which typically requires local access or a specific hardware configuration changes. No authentication is needed beyond the ability to interact with the device's driver lifecycle. The attack surface. The bug is in the probe/remove path, so exploitation would require a specific sequence of driver loading and unloading [1].

Impact

An attacker who can trigger the use-after-free could potentially cause memory corruption, leading to a system crash (denial of service) or, in more severe cases, arbitrary code execution in kernel context. The vulnerability is classified as a high-severity issue due to the potential for privilege escalation or system compromise [1].

Mitigation

The fix has been applied in the Linux kernel stable tree. The patch moves the devm_add_action_or_reset() call to the correct position, ensuring that the clock unregister function runs after all other devm resources are freed. Users should update their kernel to a version containing this commit to mitigate the risk [1].

AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

3

Patches

3

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

3

News mentions

0

No linked articles in our index yet.