CVE-2024-42290

What it actually does

Incorrect runtime power management in irqchip/imx-irqsteer invokes sleeping functions from atomic context during clk_prepare in IRQ handler setup, triggering scheduling while atomic on i.MX8QM/i.MX8QXP during device probing.

Why it matters to the business

Causes kernel panics or boot failures on affected embedded platforms, disrupting device initialization; 44 downstream dependents amplify impact across Linux kernel ecosystems with potential operational downtime.

How an attack unfolds

Attacker triggers device probing or chained IRQ handler registration to invoke the buggy pm_runtime path; race condition in power domain activation leads to atomic context violation. Threat actors from 2024 zero-day campaigns targeting Linux kernel flaws may leverage similar uninitialized resource or race issues.

How to fix it

Apply kernel patch implementing irq_bus_lock/sync_unlock callbacks to defer power management to non-atomic context. Upgrade affected packages to fixed versions: org.webjars.npm:jquery to 3.5.0 and jquery-rails to 4.4.0 where applicable.

How to confirm the fix worked

Confirm kernel builds include the bus lock callbacks; test device probing on i.MX8 platforms without atomic scheduling warnings; verify package versions match fixed releases.

Typical attack path

1. Obtain local or physical access to trigger device probe
2. Invoke mxc_gpio_probe or irq_set_chained_handler path
3. Cause __pm_runtime_resume to call imx_irqsteer_resume
4. Trigger clk_prepare_lock from atomic context resulting in schedule bug

How to detect it

Review kernel logs for 'scheduling while atomic' with kworker and clk_prepare traces; inspect probe paths in mxc_gpio and imx_irqsteer; correlate with threat actor activity on Linux kernel races.

What your security team should do

• Prioritize kernel updates on i.MX8-based systems due to probing-time impact
• Monitor EPSS trend and ecosystem dependents for downstream exposure
• Audit IRQ chip drivers for similar atomic PM patterns