A recent Linux kernel bug, now tracked as CVE-2024-27047, highlights how even a tiny logic oversight in drivers can have serious stability consequences. This post will help you understand the bug, how exploitation can happen in the wrong circumstances, offer a step-by-step example, and explain how it got fixed.

The Vulnerability: What Went Wrong?

The problem was found in the kernel’s phy_get_internal_delay function, which is meant to fetch timing delays used by PHY (physical layer transceiver) drivers. This code is often used in networking hardware descriptions in Linux device trees.

didn’t define delay_values (i.e., didn't set up the expected array)

- but either rx-internal-delay-ps or tx-internal-delay-ps was present but set to in the device-tree,

Then, the function could try to grab a value from an empty array.

This leads to the kernel attempting to read from a null pointer — a classic “kernel oops” (essentially a crash).

> This will lead to "unable to handle kernel NULL pointer dereference at virtual address ". To avoid this kernel oops, the test should be delay >= . As there is already delay < test just before, the test could only be size == .

Let’s look at the buggy portion simplified (not actual full code)

int phy_get_internal_delay(/*args*/) {
    int delay = /* ... get from devicetree ... */;
    
    if (delay < ) {
        /* Use default path */
    } else {
        /* Try to access delay_values[delay] */
        int value = delay_values[delay];
        // crash if delay_values is empty!
    }
}

So if delay_values is NULL (array not defined) and delay >= (because the device tree *did* specify ), the line int value = delay_values[delay]; causes a null pointer dereference.

Suppose you have a device tree snippet like

ethernet-phy@ {
    tx-internal-delay-ps = <>;
    // No delay_values property in driver or DT
};

Linux boots with this, parses the property, finds delay=, and tries to look up delay_values[]. Since delay_values isn’t there, the kernel will panic with a “NULL pointer dereference”.

The system log may show

Unable to handle kernel NULL pointer dereference at virtual address 
...
PC is at phy_get_internal_delay+x2c/xc8
...

Exploitation Details

This vulnerability is not remotely exploitable by userspace apps on its own, but it *is* a denial-of-service risk for anyone who can modify the device tree or influence how kernel drivers are loaded.

Impact:

- Kernel Oops/Panic: System will hang or reboot at boot or on driver load.

Exploit Example (PoC as device tree fragment)

&phy {
    rx-internal-delay-ps = <>;
    // (Assume driver doesn't define delay_values)
};

Boot and observe the kernel panic during phy_get_internal_delay() execution.

The Official Fix

Linux maintainers addressed this by adding a proper test: only access the array if it’s definitely present. From the patch:

Patched code

if ((delay < ) || !delay_values || (size == ))
    return -EINVAL;

return delay_values[delay];

Now, trying to read from an empty array or unset pointer returns an error, instead of crashing the kernel.

Update your kernel: All major stable trees (6.1.y, 6.6.y, etc) now include the fix.

- Audit device tree files: Make sure not to specify zero delays unless you know the driver supports it.
- For Kernel Devs: Always check array size/pointers before accessing by index.

References

- Linux kernel patch commit
- CVE Details for CVE-2024-27047
- LKML Discussion

TL;DR

CVE-2024-27047 shows how easy it is for missing checks in low-level code to become reliability landmines. Always validate your pointers and array indices — especially in kernel or hardware-configuration code!


*This detailed breakdown is exclusive to our readers—please share it with anyone managing Linux-based network hardware or firmware!*

Timeline

Published on: 05/01/2024 13:15:49 UTC
Last modified on: 12/23/2024 19:14:13 UTC