CVE-2026-80751: pmdomain: mediatek: mfg: initialize prev_o in mtk_mfg_attach_dev()
In the Linux kernel, the following vulnerability has been resolved:
pmdomain: mediatek: mfg: initialize prevo in mtkmfgattachdev()
mtkmfgattachdev() reads prevo on the first iteration of its loop, in "if (prevo && prevo->freq == o->freq)", before prevo is assigned at the end of the loop body. On that first iteration, evaluating prevo reads an indeterminate value. If it is non-NULL, the condition dereferences a stale or invalid pointer, potentially faulting or incorrectly skipping the first OPP.
Initialize prevo to NULL. This matches the intent as well: there is no previous OPP to compare against on the first iteration.
Found with Clang's -Wconditional-uninitialized.
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems running a Linux kernel with the MediaTek MFG power-domain driver are exposed when mtk_mfg_attach_dev() is executed. The issue is in the driver's handling of OPP entries during device attachment.
What could happen if the issue is triggered?
The first loop iteration can treat an uninitialized value as a pointer. If that value is non-NULL, the kernel may dereference a stale or invalid pointer, potentially causing a fault or incorrectly skipping the first OPP.
Is there a workaround if the kernel cannot be updated immediately?
The provided information identifies initializing prev_o to NULL as the fix. No configuration workaround or mitigation is provided.
How can I tell whether my kernel contains the fix?
Check whether mtk_mfg_attach_dev() initializes prev_o to NULL before its loop. The referenced stable commits contain the resolved change.