CVE-2024-53193: clk: clk-loongson2: Fix memory corruption bug in struct loongson2_clk_provider
In the Linux kernel, the following vulnerability has been resolved:
clk: clk-loongson2: Fix memory corruption bug in struct loongson2_clk_provider
Some heap space is allocated for the flexible structure `struct
clk_hw_onecell_data` and its flexible-array member `hws` through
the composite structure `struct loongson2_clk_provider` in function
`loongson2_clk_probe()`, 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);
Then some data is written into the flexible array:
350 clp->clk_data.hws[p->id] = hw;
This corrupts `clk_lock`, which is the spinlock variable immediately
following the `clk_data` member in `struct loongson2_clk_provider`:
struct loongson2_clk_provider {
void __iomem *base;
struct device *dev;
struct clk_hw_onecell_data clk_data;
spinlock_t clk_lock; /* protect access to DIV registers */
};
The problem is that the flexible structure is currently placed in the
middle of `struct loongson2_clk_provider` instead of at the end.
Fix this by moving `struct clk_hw_onecell_data clk_data;` to the end of
`struct loongson2_clk_provider`. Also, add a code comment to help
prevent this from happening again in case new members are added to the
structure in the future.
This change also fixes the following -Wflex-array-member-not-at-end
warning:
drivers/clk/clk-loongson2.c:32:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Security readout for executives and security teams
Plain-English summary
A Linux clock-driver layout error can overwrite a nearby kernel lock when the Loongson2 driver initializes. On an affected system, a local low-privileged user could potentially cause serious confidentiality, integrity, or availability impact. Exposure appears hardware and driver specific, not universal across Linux deployments.
Executive priority
Treat this as a high-priority kernel maintenance issue for Loongson2 infrastructure because successful memory corruption could compromise the whole system. First identify applicable hardware and driver use; systems outside that scope can be deprioritized once non-exposure is verified.
Technical view
The Loongson2 clock provider embeds a structure containing a flexible-array member before a spinlock. Allocation includes space for the array, but array writes can extend into and corrupt the adjacent clk_lock. The documented fix moves clk_data to the end of the provider structure. CVSS 3.1 is 7.8: local, low complexity, low privileges, no interaction.
Likely exposure
The bundle marks Linux 6.10, 6.11.11, 6.12.2, and 6.13 as affected, while also listing an ambiguous “0” version. Practical exposure likely requires a kernel that includes and probes the Loongson2 clock driver. Distribution backports may change exposure, so version-only conclusions are insufficient.
Exploitation context
The supplied record does not report active exploitation, and the CVE is not listed as KEV in the bundle. The CVSS vector indicates local access and low privileges are required. No evidence provided establishes a public exploit, reliable exploitation path, or observed attacks.
Researcher notes
CWE-787 applies. The defect is an intra-object overwrite caused by nesting a flexible-array-containing structure before another member. The supplied fix reorders clk_data after clk_lock and documents the layout constraint. The bundle’s version data is inconsistent or ambiguous, so commit-level and distributor-level verification is preferable.
Mitigation direction
Apply a vendor-supported kernel containing the referenced upstream fix or an equivalent backport.
Confirm distribution guidance because patched package versions may differ from upstream kernel versions.
Prioritize Loongson2 systems where the affected clock driver is present and initialized.
Use vendor-supported kernels rather than attempting an unreviewed source-level modification.
Validation and detection
Inventory kernel versions on Loongson2 systems and compare them with vendor security guidance.
Determine whether each system includes and initializes the clk-loongson2 driver.
Verify the installed kernel contains a referenced fix commit or an equivalent backport.
After updating, validate normal boot, clock operation, and system stability.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-787: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
3Timeline events
1ADP providers
4Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-787 · source CWE mapping
Out-of-bounds Write
Out-of-bounds Write represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.