CVE-2024-27037

What it actually does

Null pointer dereference in zynq_clk_setup() when kmalloc() fails under memory exhaustion, causing snprintf() to write to a null address.

Why it matters to the business

Kernel panic or system instability on affected Zynq-based Linux devices during low-memory conditions, with potential downtime for embedded or hardware-dependent workloads; low exploitability reduces immediate risk despite widespread kernel use.

How an attack unfolds

An attacker with local access exhausts system memory to force kmalloc() failure inside zynq_clk_setup(), then triggers the clock initialization path so that snprintf() dereferences the resulting null pointer and crashes the kernel.

How to fix it

Update the Linux kernel to a version containing commit 01511ac7be8e45f80e637f6bf61af2d3d2dee9db or later; rebuild and deploy the patched kernel image on Zynq platforms.

How to confirm the fix worked

Confirm the running kernel contains commit 01511ac7be8e45f80e637f6bf61af2d3d2dee9db via git log or uname; attempt to induce memory pressure and verify zynq_clk_setup() no longer uses kmalloc for the affected buffer.

Typical attack path

1. Exhaust physical memory via local processes or workloads
2. Trigger zynq clock initialization or device probe that calls zynq_clk_setup()
3. Force kmalloc() to return null
4. Execute snprintf() on the null buffer resulting in dereference and panic

How to detect it

Search kernel logs and dmesg for null pointer dereference or oops messages referencing zynq_clk_setup or clk zynq under memory pressure; correlate with kmalloc failure patterns.

What your security team should do

• Prioritize kernel upgrade on all Zynq-based production systems within standard maintenance windows
• Monitor kernel logs for null pointer dereference oops mentioning zynq_clk during low-memory events
• Apply memory pressure testing in staging environments that exercise clock setup paths