Summary:
A recent vulnerability tracked as CVE-2024-26971 was resolved in the Linux kernel, specifically in the Qualcomm clk driver for the IPQ5018 system-on-chip. This bug may lead to out-of-bounds memory access due to improperly terminated frequency table arrays. In this article, we’ll break down what went wrong, how it’s fixed, and what the risk was—using simple language and real code snippets.

What is CVE-2024-26971?

This vulnerability was found in the Linux kernel’s clock controller for Qualcomm IPQ5018 devices, under the driver: drivers/clk/qcom/gcc-ipq5018.c. Some frequency table arrays were not correctly terminated with an empty (zeroes) element. This missing element could cause functions that read these arrays—like qcom_find_freq() or qcom_find_freq_floor()—to read past the end of the array, leading to a potential out-of-bounds memory read.

Severity:
While this bug isn’t likely to result in code execution on its own, it could trigger undefined behavior (such as kernel crashes) and maybe be used as a starting point for more serious attacks, in the worst case.

Frequency Table Arrays in Qualcomm Clock Drivers

In Qualcomm clock drivers, frequency tables are arrays of struct freq_tbl that define the possible clock rates and their settings. These arrays must be terminated by a special empty element (all fields set to zero). This is so that iterating functions know when to stop.

If you forget to add a terminating empty entry, code can read right past the end of the array—possibly accessing garbage data or even causing a kernel panic.

Here’s what the problematic pattern looked like (simplified)

static struct freq_tbl ftbl_gcc_nss_noc_clk[] = {
    F(50000000,  P_XO, 12, 1, 2),
    F(100000000, P_XO, 12, , ),
    // ... no terminating empty entry!
};

Iteration functions like this one will keep going

const struct freq_tbl *f;
for (f = freq_tbl; f->freq; f++) {
    // uses f->freq, f->src, ...
}

If the array isn’t properly terminated, f->freq could be a random value in memory after the array boundary: undefined behavior and bugs follow.

To fix this, the Linux kernel commit simply appended a terminating zero entry, like so

static struct freq_tbl ftbl_gcc_nss_noc_clk[] = {
    F(50000000,  P_XO, 12, 1, 2),
    F(100000000, P_XO, 12, , ),
    { } // <--- THIS IS CRITICAL!
};

This { } entry makes f->freq == , signaling the end of the table.

Here’s a real diff from the fix

@@ -702,6 +702,7 @@ static struct freq_tbl ftbl_gcc_nss_noc_clk[] = {
        F(50000000,  P_XO, 12, 1, 2),
        F(100000000, P_XO, 12, , ),
+       { }
 };

How can it be exploited?

To exploit this directly, an attacker would probably need to trigger kernel code to specifically traverse these tables with crafted inputs, and hope for a crash/leak. But as a memory error, it should be considered dangerous.

Exploit Hypothetical

Direct reliable exploitation is unlikely without other bugs, but here is a theoretical abuse scenario:

An attacker with privileges to modify clock rates (through a malicious driver or a user-space helper with escalated permissions) could trigger out-of-bounds reads by setting up unusual clock operations. If the contents just past the array boundary include secrets, they might be leaked. More likely is a kernel crash.

PoC Sketch (not actual dangerous code, just a demonstration)

// WARNING: PoC for educational purpose ONLY

char *ptr = (char *)&ftbl_gcc_nss_noc_clk[ARRAY_SIZE];
printf("Memory after freq_tbl: %x\n", *ptr);

With the fix, this reads a known zero; before the fix, it could be anything.

Upstream Kernel Commit:

clk: qcom: gcc-ipq5018: fix terminating of frequency table arrays (commit)

Official CVE entry:

CVE-2024-26971 at NVD
- **qcom_find_freq() Source (github)](https://elixir.bootlin.com/linux/latest/source/drivers/clk/qcom/clk-branch.c#L103)

Device vendors:

Update your BSP/device tree blobs to use new kernel sources.

Users:

Make sure your device is running an up-to-date kernel, especially if it’s Internet-facing or used in sensitive networks.

Conclusion

CVE-2024-26971 shows how small missed details in system code can have large consequences. Properly terminating arrays in C is not just good hygiene—it’s needed for security and stability. Thanks to the quick response from kernel maintainers, this issue was fixed before it became a more serious problem.

Stay patched, and review your C array terminations!


*Written exclusively for you with the latest info as of June 2024.*

Timeline

Published on: 05/01/2024 06:15:13 UTC
Last modified on: 03/03/2025 17:47:59 UTC