GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux iommu/vt-d: context entry zeroed while Present, letting hardware fetch a torn entry

CVSS 8.1CVE-2026-90243Kernel, userspace & hypervisorcurated

Impact

When tearing down a context entry copied from a previous kernel (the kexec/handoff path), the kernel zeroed the whole 128-bit entry while the Present bit was still set and only then invalidated the caches, with no cacheline flush before the invalidation. The IOMMU can fetch a half-zeroed but still-Present entry, giving unpredictable translation behaviour or spurious DMA faults; on an IOMMU without coherent context-table access the zeroing may not even be visible when the invalidation is submitted. The fix applies the VT-d spec's ownership handshake - clear Present, flush, invalidate, then zero. This is a separate defect from CVE-2026-90241 with its own commits: that one frees a referenced PASID table, this one races hardware on entry ordering. Practical exposure is the device-isolation boundary during kexec-based host handoff, which is how some operators update a node without a cold boot.

Who can reach it

Local, no privileges but high attack complexity (AV:L/AC:H/PR:N) - triggering it requires hitting the hardware fetch window during copied-context teardown. Not a remote or tenant-driven path.

What to do

Take the stable-kernel fix (four stable commits listed) through your distribution and reboot affected hosts. Only systems using Intel VT-d with copied/handoff context tables are in the path. No fixed userspace knob exists; schedule it with other kernel work on a drain-and-reboot cycle.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.