CVE-2023-52873

What it actually does

Missing NULL check after mtk_alloc_clk_data allows dereference of a null pointer during Mediatek MT6779 clock initialization, resulting in a kernel crash or memory corruption.

Why it matters to the business

Kernel panic on affected devices can cause boot failure, service interruption, or system instability; the issue has been public for over two years with negligible exploitation probability.

How an attack unfolds

An attacker would need to trigger the clock driver initialization path on a vulnerable MT6779-based system; without the added check the kernel dereferences a null allocation result, but no public exploits or threat actor campaigns have been observed.

How to fix it

Update the Linux kernel to the commit fbe466f06d4ea18745da0d57540539b7b36936ae or later stable releases that contain the NULL check for mtk_alloc_clk_data.

How to confirm the fix worked

Confirm the presence of the check for the return value of mtk_alloc_clk_data in drivers/clk/mediatek/clk-mt6779.c after applying the fix; attempt to boot the affected hardware and verify absence of null-dereference oops during clock setup.

Typical attack path

1. Gain ability to load or trigger the mediatek clk-mt6779 driver
2. Force allocation failure inside mtk_alloc_clk_data
3. Kernel dereferences the unchecked null pointer
4. Resulting oops or corruption leads to denial of service

How to detect it

Search kernel logs and crash dumps for oops or panic messages originating from clk-mt6779.c around the mtk_alloc_clk_data call site; no post-exploitation artifacts are known.

What your security team should do

• Apply the referenced upstream commit or equivalent distribution kernel update immediately on all MT6779-based systems
• Prioritize devices that cannot be updated by isolating them from untrusted workloads
• Monitor kernel logs for related oops strings during driver initialization