CVE-2024-42127

What it actually does

Shared interrupt handlers in the lima DRM driver can be invoked after clocks are disabled during driver removal, allowing register accesses on an unclocked device and triggering crashes when CONFIG_DEBUG_SHIRQ is enabled.

Why it matters to the business

Unexpected kernel crashes or system instability can occur during driver unload on affected Linux systems, increasing operational risk and requiring urgent kernel updates across fleets that use the lima driver.

How an attack unfolds

An attacker with local privileges triggers lima driver removal on a kernel built with CONFIG_DEBUG_SHIRQ; the still-registered handlers fire after clocks are disabled, causing invalid register access and a crash.

How to fix it

Update the Linux kernel to a version containing commit 0d60c43df59ef01c08dc7b0c45495178f9d05a13 or later; rebuild and deploy the fixed kernel across all affected systems.

How to confirm the fix worked

Confirm the presence of commit 0d60c43df59ef01c08dc7b0c45495178f9d05a13 in the running kernel source; perform driver remove/load cycles on a DEBUG_SHIRQ kernel and verify no crash occurs.

Typical attack path

1. Obtain local access or ability to trigger module unload
2. Ensure CONFIG_DEBUG_SHIRQ is enabled in the running kernel
3. Initiate removal of the lima driver
4. Shared IRQ handlers execute after clocks are gated
5. Register access without clocks produces kernel panic

How to detect it

Search kernel logs and crash dumps for oops or panic entries that occur during lima driver removal or module unload; correlate timestamps with driver lifecycle events.

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all systems using the lima driver
• Monitor for kernel oops or panic logs during module unload operations
• Review boot and driver load configurations for unnecessary lima usage