CVE-2026-90430: iommu/tegra241-cmdqv: Publish an LVCMDQ only after it is fully initialized
In the Linux kernel, the following vulnerability has been resolved:
iommu/tegra241-cmdqv: Publish an LVCMDQ only after it is fully initialized
tegra241vintfinitlvcmdq() stores the freshly allocated vcmdq pointer to the vintf->lvcmdqs[] array, before tegra241vcmdqallocsmmucmdq() builds the vcmdq->cmdq. The error ISR dereferences that cmdq, so a latched LVCMDQ error (e.g. one inherited across a kexec) firing in this window would make tegra241vintf0handleerror() pass the still-zeroed armsmmucmdq down to armsmmucmdqskiperr(), dereferencing NULL queue register pointers.
Drop the store from tegra241vintfinitlvcmdq() and publish the vcmdq at the end of the allocation instead, with an smpstorerelease() that pairs with an smploadacquire() in the ISR, which can see a fully built LVCMDQ or NULL.
The user-owned LVCMDQ allocation moves accordingly, publishing the vcmdq once tegra241vcmdqhwinituser() succeeds, using a plain store since a user VINTF's lvcmdqs[] has no lockless reader -- the error ISR only walks the VINTF0 array.
Affected Software
Event History
Frequently Asked Questions
What systems are exposed to this issue?
The issue affects Linux kernel systems using the Tegra241 CMDQv IOMMU path, specifically during LVCMDQ initialization where the VINTF0 error ISR can inspect the LVCMDQ array.
What condition triggers the failure?
An LVCMDQ error must fire after the newly allocated queue pointer is published but before its underlying SMMU command queue has been initialized. The description identifies a latched LVCMDQ error inherited across a kexec as an example.
How would the failure appear?
The VINTF0 error handler can pass a zero-initialized arm_smmu_cmdq to the command-queue error handling path, causing a NULL dereference of queue register pointers.