CVE-2024-56682

What it actually does

NULL pointer dereference in msi_create_device_irq_domain() when the APLIC irqchip driver is probed before the IMSIC driver, leaving the parent MSI domain unavailable.

Why it matters to the business

Kernel crash or boot failure on affected RISC-V systems, leading to unplanned downtime and requiring manual intervention or reboot until the initialization order issue is resolved by a kernel update.

How an attack unfolds

An attacker with local access or the ability to influence driver probe timing can trigger the missing MSI domain condition, causing a kernel panic; no remote code execution path exists and the flaw stems purely from a probe-order race rather than malicious input.

How to fix it

Upgrade the Linux kernel to a version containing commit 285a07810ab3bcedc2bd380ebacbf6b4942a889a or later; rebuild and deploy the updated kernel image, then reboot affected systems.

How to confirm the fix worked

Confirm the running kernel contains the fix commit; verify that APLIC probe succeeds only after IMSIC has created the MSI domain and that no NULL dereference occurs during boot with both drivers present.

Typical attack path

1. System boots or module load sequence begins on RISC-V hardware using APLIC and IMSIC
2. APLIC driver probes before IMSIC has registered the parent MSI domain
3. msi_create_device_irq_domain() receives a NULL domain pointer
4. Kernel dereferences the NULL pointer and panics

How to detect it

Inspect kernel logs and dmesg output around boot time for APLIC or IMSIC probe failures, NULL pointer dereference oops, or repeated -EPROBE_DEFER messages from the irqchip driver.

• irqchip/riscv-aplic
• msi_create_device_irq_domain
• EPROBE_DEFER

What your security team should do

• Apply the kernel update containing the referenced commit as soon as it is available in your distribution
• Test the updated kernel in a staging environment that mirrors production RISC-V hardware
• Monitor boot logs for probe deferral messages after patching