CVE-2026-90241: iommu/vt-d: Tear down scalable-mode context on probe failure
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Tear down scalable-mode context on probe failure
intelpasidsetupsmcontext() walks a PCI device’s DMA aliases via pciforeachdmaalias() and programs a scalable-mode context entry for each RID. For a device with a dmaaliasmask, the callback is invoked once for the device’s own RID and once for each alias bit, all with the same pcidev, so devicepasidtablesetup() runs for multiple RIDs.
pciforeachdmaalias() stops at the first callback error. Therefore, a failure partway through the walk can leave context entries for already processed RIDs present and still pointing to the device’s PASID table.
On this error path, inteliommuprobedevice() currently jumps directly to intelpasidfreetable(), which frees the PASID table without first tearing down those context entries. The IOMMU may then walk a present context entry whose PASID table pointer references freed memory.
inteliommureleasedevice() already performs teardown before freeing the table. Apply the same ordering on the probe failure path.
devicepasidtableteardown() safely handles RIDs that were never programmed: iommucontextaddr() returns NULL when no context table has been allocated, and clearing the Present bit of an already non-present entry is a no-op. So unwind is safe for both the alias that failed and any aliases not yet reached.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel Intel VT-d IOMMU driver with scalable-mode PASID context setup are exposed when probing a PCI device that has DMA aliases. The problematic path requires setup to fail after one or more alias RIDs have already had context entries programmed.
What condition is required to trigger the stale context entries?
A failure must occur during the PCI DMA-alias walk after device_pasid_table_setup() has succeeded for at least one RID. The alias walk stops at the first callback error, leaving earlier context entries present while the PASID table is freed.
What is the consequence of the failed probe path?
The IOMMU can follow a still-present scalable-mode context entry to a PASID table pointer referencing freed memory. This occurs because the PASID table is freed before the already-programmed context entries are torn down.
Is cleanup safe if only some DMA alias RIDs were configured?
Yes. The described fix uses device_pasid_table_teardown() before freeing the PASID table, and that teardown safely handles RIDs that were never programmed.