CVE-2024-42140

What it actually does

Race condition in RISC-V kexec crash handling causes deadlock when machine_kexec_mask_interrupts attempts to acquire irqdesc spinlock followed by irq_set_irqchip_state while already in interrupt context.

Why it matters to the business

Systems may hang instead of completing a controlled crash dump or reboot, delaying recovery and incident response in production Linux environments on RISC-V hardware.

How an attack unfolds

An attacker or faulty driver triggers a kernel crash from interrupt context on RISC-V; the kexec path then deadlocks on IRQ handling instead of completing, preventing clean failover or dump collection. Listed threat actors have targeted other Linux kernel issues but no confirmed campaigns against this specific flaw.

How to fix it

Upgrade to Linux kernel 5.15.163 or later, or apply commit bb80a7911218bbab2a69b5db7d2545643ab0073d in stable trees. Rebuild and reboot affected RISC-V systems.

How to confirm the fix worked

Verify kernel version is at or above the fixed release; review dmesg or crash logs for absence of the removed irq_set_irqchip_state call in kexec paths.

Typical attack path

1. Gain code execution or trigger a fault that enters interrupt context on RISC-V Linux
2. Force a kexec crash via panic or NMI
3. machine_kexec_mask_interrupts acquires spinlock then calls irq_set_irqchip_state
4. Deadlock occurs, system stops responding instead of completing kexec

How to detect it

Review kernel crash logs and kexec-related entries in dmesg or syslog around panic events for deadlock signatures on RISC-V; no widespread exploitation indicators reported.

What your security team should do

• Prioritize patching RISC-V production kernels within standard change windows given low EPSS and no KEV listing
• Test kexec crash paths in staging environments after upgrade
• Monitor upstream stable releases for additional backports