CVE-2023-53854: 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 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.
Security readout for executives and security teams
Plain-English summary
This CVE is a Linux kernel bug in the MediaTek MT8186 audio driver. During device removal, cleanup happened in the wrong order, creating a use-after-free condition. Business exposure is likely narrow and hardware-specific, but affected embedded, Chromebook, or ARM device fleets should confirm kernel fixes.
Executive priority
Treat as a targeted kernel maintenance issue, not an emergency internet-facing exposure based on available evidence. Prioritize validation for MT8186-based managed devices and roll the fix through normal kernel update channels once vendor packages are available.
Technical view
The mt8186 ASoC driver registered audio system clocks before later devm-managed allocations. On removal, a devm cleanup action unregistered clocks before related clock objects and arrays were released, causing incorrect teardown order and a use-after-free. The fix moves the devm cleanup registration to the proper point and also prevents a leak on initialization failure.
Likely exposure
Likely limited to Linux systems using the MediaTek MT8186 audio driver on affected kernel builds. The source lists Linux 6.0, 6.1.30, 6.3.4, and 6.4 as affected, but does not provide distribution package names or complete fixed-version mapping.
Exploitation context
The provided sources do not report active exploitation, and KEV is false. The described trigger is the driver remove path during device teardown, not a remotely exposed service. No public exploit status, CVSS score, or CWE classification is included in the bundle.
Researcher notes
Evidence is strongest for the root cause and fix because the source includes the kernel commit narrative. Evidence is incomplete for exploitability, severity, reachable attack surface, and downstream vendor package status. Avoid assuming impact beyond the MT8186 ASoC driver remove path.
Mitigation direction
Update affected kernels to a vendor release containing the stable mt8186 ASoC fix.
If maintaining a kernel tree, verify the referenced stable commits or vendor backports are applied.
Prioritize MediaTek MT8186 devices that load the affected audio driver.
Monitor Linux distribution and device vendor advisories for exact fixed package versions.
Validation and detection
Inventory devices running affected Linux kernel versions on MediaTek MT8186 hardware.
Confirm whether the mt8186 ASoC audio driver is built, loaded, or enabled.
Check kernel source or vendor changelogs for the referenced stable commit IDs.
Review device lifecycle testing that exercises driver bind, unbind, suspend, or removal paths.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2023-53854 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Dec 9, 2025, 01:30 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.