CVE-2026-90428: iommu/tegra241-cmdqv: Don't run the error ISR before probe sets up vintfs
In the Linux kernel, the following vulnerability has been resolved:
iommu/tegra241-cmdqv: Don't run the error ISR before probe sets up vintfs
tegra241cmdqvprobe() requests the error IRQ before it has allocated the cmdqv->vintfs array and set cmdqv->numvintfs. A CMDQV left enabled with a latched error across a kexec fires the IRQ as soon as it is requested, and tegra241cmdqvisr() then walks the uninitialized cmdqv->vintfs array.
Request the IRQ only after cmdqv->vintfs is allocated and zeroed, so that a latched interrupt firing early runs the ISR against a valid array of NULL slots that it safely skips.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Mitigate by ensuring the error IRQ is not requested before cmdqv->vintfs is allocated and zeroed, so a latched interrupt fires the ISR only after probe sets up vintfs (iommu/tegra241-cmdqv: avoid running tegra241_cmdqv_isr before probe sets up cmdqv->vintfs and cmdqv->num_vintfs).
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's Tegra241 CMDQV IOMMU driver are relevant. The vulnerable condition specifically requires a CMDQV left enabled with a latched error across a kexec.
What triggers the unsafe interrupt-handler path?
The error IRQ can fire immediately when it is requested if an error was already latched. In the affected probe ordering, this occurs before the vintfs array has been allocated and initialized, causing the ISR to walk uninitialized state.
How does the fix prevent the issue?
The fix delays requesting the error IRQ until after the vintfs array is allocated and zeroed and its count is set. An early interrupt then encounters valid NULL array slots that the ISR safely skips.