CVE-2026-97414: ASoC: mediatek: mt8365-afe-pcm: fix possible NULL-pointer dereferences in mt8365_afe_suspend()
In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: mt8365-afe-pcm: fix possible NULL-pointer dereferences in mt8365afesuspend()
mt8365afesuspend() allocates the register backup buffer with devmkcalloc(), but does not check for allocation failure before using the returned pointer. This may lead to a NULL pointer dereference when accessing afe->regbackup[i].
Add the missing NULL check and return -ENOMEM on allocation failure after disabling the main clock.
Also propagate the return value of mt8365afesuspend() in mt8365afedevruntimesuspend() so that the suspended state is not updated when suspend fails.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In mt8365_afe_suspend(), check whether devm_kcalloc() returned NULL before accessing the register backup buffer, return -ENOMEM on allocation failure, and propagate mt8365_afe_suspend()'s return value from mt8365_afe_dev_runtime_suspend() so the suspended state is not updated when suspend fails.
Event History
Frequently Asked Questions
Under what condition can this issue be triggered?
The issue requires devm_kcalloc() to fail while mt8365_afe_suspend() is allocating its register-backup buffer. The unpatched code then dereferences the returned NULL pointer while saving registers during suspend.
What is the operational impact if allocation fails during suspend?
An affected kernel may hit a NULL-pointer dereference during the MT8365 AFE suspend path. The runtime suspend path can also incorrectly update suspended state despite the suspend operation failing.
What should systems do if the allocation fails after the fix?
The fixed suspend function disables the main clock and returns -ENOMEM rather than accessing the missing buffer. The runtime suspend caller propagates that failure, preventing suspended state from being updated.