CVE-2025-21668

What it actually does

Missing loop break condition in imx8mp_blk_ctrl_remove causes the function to iterate past valid array bounds, resulting in an out-of-bounds memory access and kernel panic during device shutdown or removal on affected ARM platforms.

Why it matters to the business

Systems using the affected Linux kernel on i.MX8MP hardware may experience unexpected crashes during reboot or shutdown sequences, leading to unplanned downtime and potential data loss in embedded or server environments; prevalence in the Linux kernel ecosystem increases exposure across many distributions and devices.

How an attack unfolds

An attacker with local access or the ability to trigger a controlled reboot can force execution of the faulty shutdown path, causing the kernel to dereference invalid memory and crash; the call trace shows the failure originates from platform_shutdown invoking dev_pm_domain_detach without the missing loop guard.

How to fix it

Upgrade the Linux kernel to the fixed commit 699cc10cc3068f9097a506eae7fe178c860dca4e or later stable releases containing the added loop break condition in pmdomain/imx8mp-blk-ctrl.

How to confirm the fix worked

Inspect the source of imx8mp_blk_ctrl_remove to confirm presence of the explicit break condition on loop termination; test reboot/shutdown sequences on patched kernels to verify absence of the prior panic path.

Typical attack path

1. Obtain local execution or reboot privileges on a vulnerable kernel
2. Trigger device shutdown or driver removal for the imx8mp-blk-ctrl component
3. imx8mp_blk_ctrl_remove enters unbounded for loop
4. Out-of-bounds access occurs leading to kernel panic

How to detect it

Review kernel logs and crash dumps for the exact call trace involving imx8mp_blk_ctrl_shutdown, dev_pm_domain_detach, and platform_shutdown; search dmesg or syslog for out-of-bounds access patterns tied to the imx8mp-blk-ctrl driver.

• imx8mp_blk_ctrl_remove
• imx8mp_blk_ctrl_shutdown
• dev_pm_domain_detach+0x8/0x48
• platform_shutdown+0x2c/0x48

What your security team should do

• Apply the kernel update containing commit 699cc10cc3068f9097a506eae7fe178c860dca4e as soon as possible on all affected i.MX8MP systems
• Monitor kernel logs for related oops/panic signatures during maintenance windows
• Prioritize patching in environments where frequent reboots occur