CVE-2023-52865

What it actually does

Missing validation of the return value from mtk_alloc_clk_data() allows a NULL pointer dereference in the MediaTek MT6797 clock driver during initialization.

Why it matters to the business

Kernel crashes or device instability on affected Linux systems, leading to downtime and potential loss of service on embedded or Android-based platforms.

How an attack unfolds

An attacker with local access or the ability to influence early boot conditions triggers the clock driver probe path so that the allocation fails, causing the subsequent dereference of the NULL pointer returned by mtk_alloc_clk_data().

How to fix it

Apply the upstream fix present in commit c26feedbc561f2a3cee1a4f717e61bdbdfb4fa92 or later; rebuild and deploy kernels containing the added NULL check for all affected stable branches.

How to confirm the fix worked

Confirm the presence of the return-value check after mtk_alloc_clk_data() in drivers/clk/mediatek/clk-mt6797.c and verify that the driver no longer oopses under allocation-failure test conditions.

Typical attack path

1. Gain local execution or control over boot parameters on an affected device
2. Force or wait for the mediatek clk-mt6797 driver to be probed during kernel initialization
3. Cause mtk_alloc_clk_data() to return NULL (resource pressure or crafted environment)
4. Trigger the unchecked dereference that results in a kernel oops or panic

How to detect it

Search kernel logs and crash dumps for oops traces that mention clk-mt6797 or mtk_alloc_clk_data; correlate with boot-time failures on mt6797 hardware.

What your security team should do

• Prioritize patching of all devices using the mt6797 clock driver
• Monitor kernel logs for NULL dereference oopses referencing clk-mt6797 during boot
• Harden allocation paths and enable kernel panic-on-oops where operationally acceptable