CVE-2022-49842: ASoC: core: Fix use-after-free in snd_soc_exit()
In the Linux kernel, the following vulnerability has been resolved:
ASoC: core: Fix use-after-free in snd_soc_exit()
KASAN reports a use-after-free:
BUG: KASAN: use-after-free in device_del+0xb5b/0xc60
Read of size 8 at addr ffff888008655050 by task rmmod/387
CPU: 2 PID: 387 Comm: rmmod
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
<TASK>
dump_stack_lvl+0x79/0x9a
print_report+0x17f/0x47b
kasan_report+0xbb/0xf0
device_del+0xb5b/0xc60
platform_device_del.part.0+0x24/0x200
platform_device_unregister+0x2e/0x40
snd_soc_exit+0xa/0x22 [snd_soc_core]
__do_sys_delete_module.constprop.0+0x34f/0x5b0
do_syscall_64+0x3a/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
...
</TASK>
It's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail,
but its ret is ignored, which makes soc_dummy_dev unregistered twice.
snd_soc_init()
snd_soc_util_init()
platform_device_register_simple(soc_dummy_dev)
platform_driver_register() # fail
platform_device_unregister(soc_dummy_dev)
platform_driver_register() # success
...
snd_soc_exit()
snd_soc_util_exit()
# soc_dummy_dev will be unregistered for second time
To fix it, handle error and stop snd_soc_init() when util_init() fail.
Also clean debugfs when util_init() or driver_register() fail.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue is a use-after-free in the ASoC audio core cleanup path. A failed initialization can leave an internal dummy platform device registered incorrectly, then cleanup unregisters it twice. The CVSS score is high, but the source describes a local kernel flaw, not a remote service exposure.
Executive priority
Treat as a high-priority kernel maintenance issue for multi-user Linux systems. It does not currently justify emergency remote-exploitation response based on the supplied sources, but kernel memory corruption with high confidentiality, integrity, and availability impact should enter the next expedited patch window.
Technical view
The bug is in snd_soc_exit() after snd_soc_util_init() failure handling in snd_soc_init(). The return value was ignored, allowing soc_dummy_dev to be unregistered during failure handling and again at module exit. KASAN reports use-after-free in device_del during module removal. The fix stops initialization on util_init failure and cleans debugfs on error paths.
Likely exposure
Exposure is likely limited to Linux systems running affected kernel versions with the ASoC core present. The supplied CVSS vector requires local access and low privileges. The affected-version data is broad and somewhat inconsistent, so kernel vendor package status should be treated as authoritative.
Exploitation context
No KEV listing is provided and the bundle does not cite active exploitation. The evidence is a kernel KASAN report and upstream stable fixes. The source does not provide public exploit status, real-world attacks, or weaponized proof-of-concept details.
Researcher notes
The source evidence points to CWE-416 in Linux ASoC core error handling. Affected-version metadata should be cross-checked because one entry repeats a commit-like value while another lists kernel versions. Avoid assuming exploitability beyond local access without additional vendor or researcher evidence.
Mitigation direction
Apply a vendor kernel update containing the relevant upstream stable fix.
Prioritize systems allowing untrusted local users or shared shell access.
Check Linux distribution advisories for backported fixes before judging by version alone.
Where feasible, reduce unnecessary local account access until patched.
Validation and detection
Inventory Linux kernel versions and vendor package release levels.
Confirm whether the kernel includes one of the referenced stable fixes.
Identify systems using or loading the ASoC core module path.
Review kernel logs for KASAN, device_del, snd_soc_exit, or module-removal crashes.
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.
cwe · low confidence lookup
CWE-416: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
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.
1CVSS vectors
3Timeline events
1ADP providers
9Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-416 · source CWE mapping
Use After Free
Use After Free represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.