Linux Kernel
CVE-2024-53192
HIGH
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Local access required (driver-level initialization on specific hardware); PR:L since a basic user account can trigger the load path; full kernel memory corruption yields C/I/A:H.
Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).
CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Lifecycle Timeline
5DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
clk: clk-loongson2: Fix potential buffer overflow in flexible-array member access
Flexible-array member hws in struct clk_hw_onecell_data is annotated with the counted_by() attribute. This means that when memory is allocated for this array, the _counter_, which in this case is member num in the flexible structure, should be set to the maximum number of elements the flexible array can contain, or fewer.
In this case, the total number of elements for the flexible array is determined by variable clks_num when allocating heap space via devm_kzalloc(), as shown below:
289 struct loongson2_clk_provider *clp; ... 296 for (p = data; p->name; p++) 297 clks_num++; 298 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num), 300 GFP_KERNEL);
So, clp->clk_data.num should be set to clks_num or less, and not exceed clks_num, as is currently the case. Otherwise, if data is written into clp->clk_data.hws[clks_num], the instrumentation provided by the compiler won't detect the overflow, leading to a memory corruption bug at runtime.
Fix this issue by setting clp->clk_data.num to clks_num.
AnalysisAI
Buffer overflow in the Linux kernel's clk-loongson2 clock driver allows a local low-privileged user on Loongson2-based systems to corrupt kernel memory, potentially enabling privilege escalation to root. The flaw stems from a mismatch between the allocated flexible array size and the counter field governing compiler-level bounds instrumentation: the counted_by() annotation on hws relies on clk_data.num being set correctly, but the driver was leaving it inconsistent with the allocated clks_num, defeating sanitizer detection of out-of-bounds writes. No public exploit has been identified and EPSS sits at 0.23% (13th percentile), indicating negligible opportunistic exploitation risk, though kernel memory corruption primitives carry inherent escalation potential once triggered.
Technical ContextAI
The affected code resides in drivers/clk/clk-loongson2.c within the Linux kernel, which manages clock hardware on Loongson2 MIPS-derived SoCs (CPE: cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*). The root cause is CWE-120 (Buffer Copy without Checking Size of Input), specifically a misuse of C's flexible array member pattern with the counted_by() attribute - a Clang/GCC sanitizer annotation that links a flex-array's runtime bound to a named counter field. During probe, devm_kzalloc() allocates struct_size(clp, clk_data.hws, clks_num) bytes, correctly sizing the heap block for clks_num clock entries. However, the driver then failed to assign clp->clk_data.num = clks_num, leaving the sanitizer's view of array capacity incorrect. Any subsequent write to clp->clk_data.hws[clks_num] (one past the last valid index) would corrupt adjacent kernel heap memory without the compiler-instrumented bounds check firing.
RemediationAI
Apply the upstream kernel stable patches corresponding to your kernel series: commit 02fb4f0084331ef72c28d0c70fcb15d1bea369ec, 1bf8877150128c3abd9d233886a05f6966fbf0c7, or b96fc194984d0c82de1ca2b4166b35b1298b216c (all available at git.kernel.org/stable). Distributions shipping kernels for Loongson2 targets (e.g., Loongnix, AOSC OS for loongarch/mips) should be checked for updated packages incorporating these stable backports. No exact released kernel version is independently confirmed as fully patched across all stable branches from the available reference data. As a compensating control on unpatched systems, restrict local user access to Loongson2 machines to trusted personnel only, since exploitation requires local shell access with at least low privileges. Disabling or blacklisting the clk-loongson2 module (modprobe -r clk-loongson2) would eliminate the attack surface but may break clock management and render the system unusable, so this trade-off is only viable in controlled lab contexts.
Same weakness CWE-120 – Classic Buffer Overflow
View allSame technique Buffer Overflow
View allShare
External POC / Exploit Code
Leaving vuln.today