CVE-2024-42319

What it actually does

Incorrect ordering of devm_mbox_controller_register() before devm_pm_runtime_enable() in the mtk-cmdq mailbox driver causes pm_runtime_get_sync() to be invoked after pm_runtime_disable() during device unbind, triggering a WARN_ON.

Why it matters to the business

Systems using affected MediaTek command queue hardware may experience kernel warnings or driver instability during module unload or device removal, with moderate operational impact due to high downstream prevalence.

How an attack unfolds

An attacker with local access triggers driver unbind (via module removal or device hot-unplug) after the probe sequence has registered resources in the wrong order, causing the runtime power management call to execute post-disable.

How to fix it

Update the Linux kernel to a version containing the fix that moves devm_mbox_controller_register() after devm_pm_runtime_enable() in cmdq_probe(). Apply vendor backports if available for the running kernel series.

How to confirm the fix worked

Confirm the corrected probe ordering is present in the source, rebuild, and verify no WARN_ON occurs on module unbind or device removal under pm_runtime conditions.

Typical attack path

1. Gain local access to a system with the mtk-cmdq driver loaded
2. Trigger cmdq_remove() by unloading the module or detaching the device
3. Observe devm_pm_runtime_disable() execute before devm_mbox_controller_unregister()
4. Cause cmdq_mbox_shutdown() to call pm_runtime_get_sync() after disable, hitting the warning path

How to detect it

Search kernel logs for the exact WARN_ON condition involving pm_runtime_get_sync() during cmdq_mbox_shutdown or mbox_controller_unregister; examine dmesg output around module unload or device detach events.

What your security team should do

• Prioritize patching kernel packages on all systems exposing the mtk-cmdq driver due to 886 downstream dependents
• Monitor for the described WARN_ON in kernel logs as an immediate indicator of exposure
• Test driver unload paths in staging environments before deploying to production