CVE-2024-26969

What it actually does

Missing empty-element terminator in frequency table arrays for the IPQ8074 GCC clock driver allows qcom_find_freq() and qcom_find_freq_floor() to perform out-of-bounds reads while walking the tables.

Why it matters to the business

Systems using the IPQ8074 SoC may experience kernel crashes, memory corruption, or unexpected clock behavior when clock-frequency lookups occur, increasing downtime and patching urgency on embedded Linux devices.

How an attack unfolds

An attacker with the ability to trigger clock-frequency queries (for example through user-space clock APIs or driver initialization paths) causes the kernel to traverse past the end of an unterminated frequency table, resulting in out-of-bounds memory access that can be leveraged for denial of service or further memory-corruption primitives.

How to fix it

Update the Linux kernel to the commit e117c6e2d1617520f5f7d7f6f6b395f01d8b5a27 or later; rebuild and deploy the kernel image containing the added empty-element terminators for all affected frequency tables.

How to confirm the fix worked

Confirm the presence of the terminating entry (typically a zeroed struct) at the end of each frequency table in drivers/clk/qcom/gcc-ipq8074.c after applying the fix; boot the updated kernel and exercise clock-frequency APIs to verify absence of out-of-bounds accesses via KASAN or similar tooling.

Typical attack path

1. Obtain local or remote code execution context on an IPQ8074-based Linux system
2. Invoke clock-frequency lookup functions that iterate the gcc-ipq8074 tables
3. Trigger out-of-bounds read due to missing terminator entry
4. Use resulting memory corruption for privilege escalation or denial of service

How to detect it

Review kernel logs for unexpected page faults or KASAN reports referencing qcom_find_freq during clock operations; examine dmesg and ftrace output for clock driver initialization anomalies on IPQ8074 hardware.

What your security team should do

• Prioritize kernel upgrades on all IPQ8074-based devices within standard change windows
• Monitor vendor BSP releases for backported patches
• Enable kernel hardening features such as KASAN in test environments to catch similar issues early