CVE-2026-97515: i3c: master: svc: Prevent IRQ storm from false SLVSTART on NPCM845
In the Linux kernel, the following vulnerability has been resolved:
i3c: master: svc: Prevent IRQ storm from false SLVSTART on NPCM845
On NPCM845, when a target on the I3C bus gets stuck holding SDA low, the controller reports a false Master Request (MR) in-band interrupt event. The driver handles this by emitting a STOP condition to restore the bus.
However, the hardware quirk SVCI3CQUIRKFALSESLVSTART indicates that emitting a STOP condition may spuriously set the SLVSTART interrupt status bit. In the Master Request case, this creates a feedback loop: the STOP triggers a new SLVSTART event, the IRQ handler fires again, the controller still reports an MR type, another STOP is emitted, and the cycle repeats indefinitely, resulting in an IRQ storm that can lock up the CPU.
Clear the SLVSTART status bit explicitly after emitting the STOP in the Master Request IBI handler when the SVCI3CQUIRKFALSESLVSTART quirk is set. This breaks the feedback loop without affecting normal SLVSTART processing, which is already guarded in the top-level IRQ handler by checking that MSTATUS is in SLVREQ state.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
On NPCM845 when handling the SVC_I3C_QUIRK_FALSE_SLVSTART condition, explicitly clear the SLVSTART status bit after emitting the STOP condition to prevent a false SLVSTART IRQ storm.
Event History
Frequently Asked Questions
Which systems are realistically exposed to this issue?
Systems using the Linux kernel I3C SVC master driver on NPCM845 hardware are exposed when an I3C target can become stuck holding SDA low. The false SLVSTART behavior is tied to the SVC_I3C_QUIRK_FALSE_SLVSTART hardware quirk.
What condition triggers the CPU lockup?
A target holding SDA low can cause the controller to report a false Master Request in-band interrupt. The driver's recovery STOP can then spuriously reassert SLVSTART, creating an endless interrupt-handling loop that produces an IRQ storm and can lock up the CPU.
What is the mitigation if the fix cannot be applied immediately?
The provided information identifies the triggering condition as an I3C target stuck holding SDA low. No configuration-only workaround is specified; avoiding or correcting the affected bus/device fault is the only mitigation described by the available data.
How does the fix prevent the repeated interrupts?
After issuing the recovery STOP for a Master Request event, the driver explicitly clears the SLVSTART status bit when the false-SLVSTART quirk is present. This breaks the STOP-to-SLVSTART feedback loop while leaving normal SLVSTART handling unchanged.