CVE-2023-53854
published 2025-12-09CVE-2023-53854: 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…
PriorityP424
EPSS
0.20%
9.5th percentile
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.
Affected
10 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.37-1 (bookworm) | linux 6.1.37-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 55b423d5623ccd6785429431c2cf5f3e073b73ba < 3e56a1c04882852e3e7d6c59756a16211ebbc457 | 3e56a1c04882852e3e7d6c59756a16211ebbc457 |
| linux | linux | >= 55b423d5623ccd6785429431c2cf5f3e073b73ba < dffd9e2b57cb845930fa885aa634a847ba2130dd | dffd9e2b57cb845930fa885aa634a847ba2130dd |
| linux | linux | >= 55b423d5623ccd6785429431c2cf5f3e073b73ba < a93d2afd3f77a7331271a0f25c6a11003db69b3c | a93d2afd3f77a7331271a0f25c6a11003db69b3c |
| linux | linux_kernel | >= 0 < 6.1.37-1 | 6.1.37-1 |
| linux | linux_kernel | >= 0 < 6.3.7-1 | 6.3.7-1 |
| linux | linux_kernel | >= 0 < 6.3.7-1 | 6.3.7-1 |
| linux | linux_kernel | >= 6.0.0 < 6.1.30 | 6.1.30 |
| linux | linux_kernel | >= 6.2.0 < 6.3.4 | 6.3.4 |
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-8mp2-mjh9-w6fj: In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: mt8186: Fix use-after-free in driver remove path
When devm runs
ghsa_unreviewed·2025-12-09
CVE-2023-53854 GHSA-8mp2-mjh9-w6fj: In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: mt8186: Fix use-after-free in driver remove path
When devm runs
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
OSV
CVE-2023-53854: In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8186: Fix use-after-free in driver remove path When devm runs fu
osv·2025-12-09
CVE-2023-53854 CVE-2023-53854: In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8186: Fix use-after-free in driver remove path When devm runs fu
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_aud
OSV
ASoC: mediatek: mt8186: Fix use-after-free in driver remove path
osv·2025-12-09
CVE-2023-53854 ASoC: mediatek: mt8186: Fix use-after-free in driver remove path
ASoC: mediatek: mt8186: Fix use-after-free in driver remove path
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 orde
Red Hat
kernel: ASoC: mediatek: mt8186: Fix use-after-free in driver remove path
vendor_redhat·2025-12-09
CVE-2023-53854 kernel: ASoC: mediatek: mt8186: Fix use-after-free in driver remove path
kernel: ASoC: mediatek: mt8186: Fix use-after-free in driver remove path
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
Debian
CVE-2023-53854: linux - In the Linux kernel, the following vulnerability has been resolved: ASoC: media...
vendor_debian·2023
CVE-2023-53854 CVE-2023-53854: linux - In the Linux kernel, the following vulnerability has been resolved: ASoC: media...
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_aud
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2023-53854 kernel: ASoC: mediatek: mt8186: Fix use-after-free in driver remove path
bugzilla·2025-12-09
CVE-2023-53854 CVE-2023-53854 kernel: ASoC: mediatek: mt8186: Fix use-after-free in driver remove path
CVE-2023-53854 kernel: ASoC: mediatek: mt8186: Fix use-after-free in driver remove path
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 d
Wiz
CVE-2023-53854 Impact, Exploitability, and Mitigation Steps | Wiz
blogs_wiz
CVE-2023-53854 CVE-2023-53854 Impact, Exploitability, and Mitigation Steps | Wiz
## CVE-2023-53854 :
Linux Debian vulnerability analysis and mitigation
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,
t
2025-12-09
Published