CVE-2026-90424: iommu/tegra241-cmdqv: Fix VINTF0 leak on the init-failure path
In the Linux kernel, the following vulnerability has been resolved:
iommu/tegra241-cmdqv: Fix VINTF0 leak on the init-failure path
tegra241cmdqvinitstructures() allocates VINTF0 with kzallocobj(), inits it, and preallocates its logical VCMDQs. Two of its error paths leak.
When tegra241cmdqvinitvintf() fails it returns before VINTF0 reaches the cmdqv->vintfs[] array, so the devres unwind on probe failure cannot reach it; free it directly there.
A later VCMDQ preallocation failure instead leaves VINTF0 published, and so this time the unwind does reach tegra241cmdqvremovevintf(), which then frees it from vintf->hypown. But tegra241vintfhwinit() sets that flag only afterward, from a HW read-back, so the still-uninited VINTF0 reads as guest-owned and leaks, with mutexdestroy() and idadestroy() run on fields it never set up.
Decide ownership from vintf->idx instead, the index assigned when its id is allocated: idx 0 is the kernel-owned VINTF0, while idx >= 1 marks a guest VINTF. So the in-kernel free decision in tegra241cmdqvremovevintf() and tegra241vintffreelvcmdq() now keys on idx too, and hypown stays a pure HW-readback state.
Affected Software
Event History
Frequently Asked Questions
What systems are exposed to this issue?
Systems using the Linux kernel Tegra241 CMDQV IOMMU driver are exposed when its initialization reaches either the VINTF initialization failure path or a later logical VCMDQ preallocation failure path.
What has to happen for the leak to occur?
The issue requires an initialization failure: either tegra241_cmdqv_init_vintf() fails before VINTF0 is published, or logical VCMDQ preallocation fails after VINTF0 is published but before its hardware ownership state is initialized.
How does the fix prevent the leak?
The fix directly frees unpublished VINTF0 objects on the early failure path. For published objects, cleanup decisions use the allocated VINTF index, where index 0 identifies the kernel-owned VINTF0 and indexes of 1 or greater identify guest VINTFs, rather than relying on an uninitialized hardware-readback ownership flag.