CVE-2024-53192

What it actually does

Failure to initialize the counted_by field in clk_hw_onecell_data allows out-of-bounds writes into the flexible hws array when clks_num elements are allocated but num is left unset or too large.

Why it matters to the business

Memory corruption in the kernel clock subsystem can crash systems or allow local privilege escalation, affecting stability and security of Loongson-based Linux deployments.

How an attack unfolds

An attacker with the ability to trigger clk provider registration supplies a data array sized by clks_num; because num is not set to clks_num, subsequent accesses to clk_data.hws[clks_num] bypass compiler bounds checks and corrupt adjacent kernel memory.

How to fix it

Upgrade to a kernel containing the fix that sets clp->clk_data.num = clks_num immediately after allocation; apply the patch or newer mainline release that initializes the counted_by member correctly.

How to confirm the fix worked

Inspect the clk-loongson2 probe path to confirm clk_data.num is assigned clks_num before any hws[] access; recompile with counted_by instrumentation and verify no out-of-bounds warnings are emitted during allocation.

Typical attack path

1. Identify a Loongson2 platform exposing the clk-loongson2 driver
2. Trigger devm_kzalloc allocation of clk_hw_onecell_data with clks_num elements
3. Cause the driver to write past the end of the hws array before num is corrected
4. Leverage resulting memory corruption for kernel code execution or denial of service

How to detect it

Search kernel logs and crash dumps for out-of-bounds warnings or memory corruption signatures around clk_hw_onecell_data allocation in the loongson2 clock driver; correlate with processes that register clock providers.

What your security team should do

• Prioritize kernel updates on all Loongson2 systems within the normal patching cycle
• Monitor for local privilege-escalation attempts targeting clock driver code paths
• Review downstream kernel forks for the same missing num assignment