CVE-2026-90425: iommu/tegra241-cmdqv: Require exactly one Stream ID for a vSID
In the Linux kernel, the following vulnerability has been resolved:
iommu/tegra241-cmdqv: Require exactly one Stream ID for a vSID
tegra241vintfinitvsid() maps a guest vSID to a single physical Stream ID taken from master->streams[0], and only warns when the device does not have exactly one stream. A device with several streams gets only its first one mapped, so a guest vSID invalidation cannot reach the others' ATC and IOTLB entries; a device with none makes master->streams a ZEROSIZEPTR, read out of bounds.
Reject the mapping with -EOPNOTSUPP if master->numstreams is not one.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Reject the mapping with -EOPNOTSUPP when master->num_streams is not one (iommu/tegra241-cmdqv: Require exactly one Stream ID for a vSID, so guest vSID invalidation cannot reach other devices’ ATC and IOTLB).
Linux kernel (iommu/tegra241-cmdqv) vSID/stream mapping validation = Require exactly one Stream ID for a vSID
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel's tegra241-cmdqv IOMMU path are affected when a guest vSID is mapped for a device whose stream count is not exactly one. Devices with multiple streams can retain untranslated-cache entries for streams other than the first, while devices with no streams can trigger an out-of-bounds read.
What condition is required to trigger the problem?
The affected path is reached when tegra241_vintf_init_vsid() attempts to map a guest vSID for a master device with either zero streams or more than one stream. The prior behavior mapped only master->streams[0] rather than rejecting that unsupported stream configuration.
What is the mitigation if the fix cannot be applied immediately?
Avoid configuring or mapping guest vSIDs for devices that do not have exactly one Stream ID. In particular, do not use this vSID mapping path for devices with zero or multiple streams.
How does the fix change behavior?
The corrected behavior rejects vSID mapping with -EOPNOTSUPP unless master->num_streams equals one. This prevents both partial mapping of multi-stream devices and access to a stream entry when no streams exist.