CVE-2026-89450

What it actually does

The tegra241-cmdqv IOMMU driver accepts a guest-supplied virtual Stream ID that does not fit the 20-bit VIRT_SID field of SID_MATCH. Only values above UINT_MAX are rejected, so a wider virt_sid is shifted into the register and high bits are dropped. A value such as 0x80000000 programs SID_MATCH as a valid match on vSID 0, aliasing the guest entry onto the wrong Stream ID. IOMMU stream isolation between virtual devices is therefore broken, with changed-scope impact on DMA confidentiality, integrity, and availability.

Why it matters to the business

On hosts that virtualize NVIDIA Tegra 241 IOMMU command queues, a malicious or compromised guest can undermine DMA isolation and affect the hypervisor or other tenants—data exposure, unauthorized DMA, or host/guest disruption. The issue is not listed in KEV, has no known in-the-wild exploitation, and has no published exploit maturity, but CVSS 8.8 with scope change makes it urgent for virtualization and embedded Tegra platforms. It has been public for about 30 days; treat unpatched kernels as a high-priority patching item even without a CISA due date.

How an attack unfolds

An attacker who already controls a guest (or a VMM path that forwards guest virt_id) supplies an oversized vSID. The host’s tegra241_vintf_init_vsid() bound check does not enforce the 20-bit hardware field, so the value is programmed with a shift-and-enable write that truncates bits above bit 20. Hardware then matches the wrong Stream ID (commonly vSID 0). The guest’s command-queue/DMA traffic is associated with another stream identity, allowing cross-stream aliasing that can observe, inject, or disrupt DMA beyond the guest’s isolation boundary. No named threat actors or ransomware campaigns are associated with this CVE.

How to fix it

Install a Linux kernel that includes the iommu/tegra241-cmdqv fix: validate virt_sid with FIELD_MAX() against the SID_MATCH VIRT_SID width and program the register with FIELD_PREP() so the value cannot alias another Stream ID. Prefer distro or vendor stable kernels that backported that commit; no per-package fixed versions were supplied with this record, so confirm via kernel changelog or git history for tegra241-cmdqv. Until patched, do not expose tegra241 command-queue virtualization to untrusted guests, and restrict who can create or configure virtual IOMMU interfaces. Reboot onto the patched kernel so the module/driver is actually replaced.

How to confirm the fix worked

Confirm the running kernel tree contains the tegra241_vintf_init_vsid() FIELD_MAX()/FIELD_PREP() SID_MATCH width check (grep kernel sources or distro advisory notes for iommu/tegra241-cmdqv). On deployed hosts, record uname -r and vendor kernel package version against the advisory, and verify tegra241-cmdqv is loaded only from the patched image. Negative test: oversized virt_sid values must be rejected rather than programmed. Inventory whether the platform uses Tegra 241 IOMMU CMDQV at all; systems without that driver are not exposed.

Typical attack path

1. Obtain local code execution or equivalent control inside a guest VM on a host using tegra241-cmdqv IOMMU virtualization
2. Cause the VMM to initialize a virtual interface with a guest-controlled virt_sid wider than the 20-bit SID_MATCH field (for example a value with bits set above bit 19)
3. Rely on the kernel accepting the value because it only rejects virt_sid greater than UINT_MAX
4. Trigger programming of SID_MATCH via a shift-or-enable write that drops high bits and enables a match on the truncated identity (vSID 0)
5. Use the aliased Stream ID so guest DMA or command-queue traffic is treated as belonging to another stream
6. Abuse the isolation failure to access, modify, or disrupt DMA for another device or tenant, impacting host or sibling-guest confidentiality, integrity, or availability

How to detect it

There is no public exploit, KEV listing, or named campaign, so compromise is unlikely to leave a unique malware fingerprint. Hunt on Tegra 241 virtualization hosts for IOMMU and DMA anomalies around the time a guest configured a virtual stream: kernel logs from the tegra241-cmdqv path, unexpected SID mismatches or IOMMU faults, guests that programmed unusual virt_id/vSID values, and DMA errors or data corruption affecting a different VM or device than the one issuing traffic. Compare pre-patch kernel versions and whether untrusted guests were allowed to initialize virtual IOMMU interfaces. Timeline review of guest create/attach events versus host IOMMU faults is more useful than file-hash IOCs.

What your security team should do

• Prioritize kernel updates on any host that loads iommu/tegra241-cmdqv or offers Tegra 241 IOMMU command-queue virtualization to guests
• Until patched, prevent untrusted VMs from attaching virtual IOMMU/CMDQV interfaces and limit who can configure vSID/virt_id
• Track distro/vendor stable backports; this record has no fixed-version list, so verify the specific commit is present before closing the finding
• Treat as changed-scope isolation risk (guest toward host/other tenants), not a remote worm; still patch within normal critical-kernel SLAs given CVSS 8.8
• Hunt for unexplained IOMMU/DMA faults and cross-VM device interference on Tegra 241 virtualization hosts, noting no KEV, ransomware, or named-actor activity is documented
• After patching, reboot and attest kernel version/module build so the old driver cannot remain loaded