CVE-2026-90426: iommu/tegra241-cmdqv: Free the error IRQ before tearing down VINTFs
In the Linux kernel, the following vulnerability has been resolved:
iommu/tegra241-cmdqv: Free the error IRQ before tearing down VINTFs
tegra241cmdqvremove() tears each VINTF down first, then calls freeirq(). Tearing a VINTF down frees vintf0 and clears cmdqv->vintfs[0]. An error in that window makes tegra241cmdqvisr() read the stale slot and hand it to tegra241vintf0handleerror(), which dereferences a NULL or freed pointer.
Free the IRQ before tearing the VINTFs down. freeirq() waits for in-flight handlers to finish and blocks new ones, so no ISR can observe a VINTF as it is torn down.
Note: a user-owned VINTF (viommu) could outlive this teardown, which unmaps cmdqv->base and frees cmdqv->vintfs, so a later viommu close then touches freed memory. This is neither introduced nor fixed here: a physical IOMMU is not a pluggable device, so iommufd by design holds no reference on the one behind a viommu, and this teardown is not expected while that viommu is still alive.
Affected Software
Event History
Frequently Asked Questions
What condition is required for this issue to occur?
The Tegra241 CMDQV error interrupt must occur during device removal after a VINTF has been torn down but before the error IRQ is freed. In that window, the interrupt handler can access a cleared or freed VINTF entry.
What is the impact of triggering the race?
The error interrupt handler can pass a stale VINTF slot to the error-handling path, resulting in a NULL-pointer or use-after-free dereference.
Does this change address viommu instances that remain open during teardown?
No. A user-owned VINTF through viommu can outlive teardown and later access freed CMDQV memory when closed; the provided data states this behavior was neither introduced nor fixed by this change and that teardown is not expected while such a viommu remains alive.