CVE-2023-54221

What it actually does

The vulnerability is a memory leak and incomplete error unwinding in imx93_clocks_probe caused by direct returns without calling unregister_hws, use of kzalloc instead of devm_kzalloc, and of_iomap without automatic cleanup, leaving hardware registrations and mapped regions active on failure paths.

Why it matters to the business

Systems using affected i.MX93 clock initialization may experience gradual kernel memory exhaustion or resource leaks during boot-time error conditions, increasing operational risk of instability on embedded or server deployments with high boot frequency or transient hardware issues.

How an attack unfolds

An attacker with local access or the ability to influence device-tree configuration induces a failure inside imx93_clocks_probe; the missing goto and non-managed allocations leave clocks registered and memory allocated, resulting in a persistent leak that can be triggered repeatedly to deplete resources.

How to fix it

Update the Linux kernel to a version containing commit 280a5ff665e12d1e0c54c20cedc9c5008aa686a5 or later; replace kzalloc with devm_kzalloc and of_iomap with devm_of_iomap in the imx93 clock driver, and ensure all error paths execute unregister_hws.

How to confirm the fix worked

Inspect the imx93 clock driver source for the presence of devm_kzalloc, devm_of_iomap, and the goto unregister_hws statements on the previously missing error paths; verify the running kernel tree contains commit 280a5ff665e12d1e0c54c20cedc9c5008aa686a5.

Typical attack path

1. Gain ability to trigger probe errors via device-tree manipulation or hardware fault injection
2. Cause imx93_clocks_probe to hit an error return before unregister_hws
3. Repeat to accumulate leaked memory and ioremap regions
4. Monitor for kernel memory pressure or OOM conditions

How to detect it

Review kernel boot logs and dmesg for repeated imx93 clock probe failures; use kmemleak reports or slabinfo to identify persistent allocations originating from the clock driver after failed probes; correlate with device-tree changes or hardware initialization errors.

What your security team should do

• Prioritize kernel upgrade on all i.MX93-based systems within standard patch windows given low EPSS and no KEV listing
• Audit custom device trees and boot configurations that could trigger probe failures
• Enable kernel memory-leak detectors (kmemleak) in test environments to validate the fix
• Monitor upstream stable branches for any backports of the referenced commit