CVE-2024-27037 - Linux Kernel zynq_clk_setup() Null Pointer Dereference Vulnerability Explained

On February 25, 2024, a critical vulnerability was patched in the Linux kernel, specifically affecting the Zynq clock driver. Tracked as CVE-2024-27037, this issue could cause serious system crashes via a null pointer dereference when memory runs out. Here, we’ll break it down in simple terms, show what happened in the code, give an example exploit scenario, and share relevant references.

What’s the Vulnerability?

The bug lives inside the function zynq_clk_setup() in the Zynq clock driver code. It happens when the function tries to allocate memory using kmalloc(). If there’s no physical memory left, kmalloc() returns NULL. The bad news? The code did not check if kmalloc() failed! It went ahead and used snprintf() to write to that null address, causing a null pointer dereference—crashing your kernel.

Let’s look at the vulnerable code before the patch

static void __init zynq_clk_setup(struct device_node *node)
{
    char *clk_name;
    // ... other setup code ...

    clk_name = kmalloc(32, GFP_KERNEL);
    // * No check if kmalloc failed! *
    snprintf(clk_name, 32, "clk_%s", node->name);

    // ... do stuff with clk_name ...

    kfree(clk_name);
}

What’s the problem?
If kmalloc() fails, clk_name is NULL. The next line with snprintf(clk_name, ...) will try to write to NULL. That’s a classic null pointer dereference crash!

The patch switches to a safer approach using a stack variable (no heap allocation)

static void __init zynq_clk_setup(struct device_node *node)
{
    char clk_name[32]; // Safe stack allocation

    snprintf(clk_name, sizeof(clk_name), "clk_%s", node->name);

    // ... do stuff with clk_name ...
}

No heap memory, no kmalloc, no NULL checks needed—much safer!

How Could It Be Exploited?

This isn’t a remote code execution bug—regular users won’t exploit this easily. It happens when the system is so low on memory that kmalloc() fails during hardware clock setup. Most likely, a denial-of-service scenario if someone finds a way to exhaust memory at just the right time, causing the kernel to crash during driver initialization (think: unprivileged user spamming driver reloads or poking at device trees with malformed data).

References

- Linux Kernel Commit Fixing CVE-2024-27037
- NIST National Vulnerability Database: CVE-2024-27037
- Linux Kernel: zynq clock driver source code (drivers/clk/clk-zynq.c)

Routine code audits help eliminate these "classic" bugs before attackers can find them.

Stay updated with kernel patches—especially if you run critical embedded systems, like those using Zynq devices!


If you want to know more or are unsure if you’re affected, review the Linux kernel commit linked above or talk with your Linux distribution’s security team.

Timeline

Published on: 05/01/2024 13:15:49 UTC
Last modified on: 11/07/2024 18:35:07 UTC