CVE-2023-53854

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

published December 9, 2025

CVSS
—
EPSS
0%
Percentile
11.7
In the wild
Unconfirmed
What it is

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.

The record
Technical detail
CVSS
Not scored
CVSS v4.0
Not supplied
EPSS
0.00219 · 11.7th percentile
Published
2025-12-09T01:30Z
EPSS history
Timeline
  • 09 DEC 01:30Z
    ASoC: mediatek: mt8186: Fix use-after-free in driver remove path
    cvelistv5