CVE-2026-90243 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Clear Present bit before tearing down copied context entry
copied_context_tear_down() zeroes the 128-bit context entry with context_clear_entry() while the Present bit is still set, and only then issues the context-cache and IOTLB invalidations. This leaves a window in which hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behaviour or spurious faults. While x86 provides strong write ordering, the compiler may reorder the writes to the two 64-bit halves of the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes.
There is no cacheline flush before the invalidation either, so on an IOMMU without coherent access to the context table the zeroed entry may not be visible to hardware at the point the invalidation is submitted.
Apply the same ownership handshake described in the VT-d spec, Section 6.5.3.3 ("Guidance to Software for Invalidations"): clear only the Present bit, flush it out to the IOMMU, perform the invalidations, and only then zero the remainder of the entry.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability in question resides within the Intel VT-d IOMMU driver subsystem of the Linux kernel, specifically affecting the context entry teardown process managed by the copied_context_tear_down function. This flaw represents a race condition rooted in improper synchronization between software state modifications and hardware visibility during resource cleanup operations. The core technical issue arises from the sequence in which memory fields are cleared before issuing invalidation commands to the IOMMU hardware. Specifically, the existing implementation zeroes out all 128 bits of the context entry using context_clear_entry while the Present bit remains set. Only after this bulk zeroing operation does the driver submit context-cache and Input Output Translation Lookaside Buffer (IOTLB) invalidations to notify the hardware that the mapping is no longer valid. This ordering creates a critical window where the IOMMU may fetch or access the context entry during its update cycle, resulting in a partially torn state where some fields are zeroed while others retain their previous values and the Present bit indicates validity.
From an architectural perspective, this vulnerability exploits two distinct failure modes related to memory consistency and atomicity guarantees. First, although x86 architecture provides strong write ordering for CPU cores, it does not guarantee that writes to different parts of a 128-bit structure are perceived as atomic by external devices like the IOMMU. The compiler may reorder or split these writes into separate 64-bit operations, meaning the hardware might observe an intermediate state where half the entry is cleared but the Present bit still signals that the mapping is active. Second, and more critically, there is a lack of cache coherency management for systems where the IOMMU does not have direct coherent access to system memory via DMA-coherent pathways. Without explicit cache line flushes prior to submitting invalidation commands, the zeroed data may remain in CPU caches and thus be invisible to the hardware at the moment the invalidation request is processed. Consequently, the hardware continues to operate based on stale or partially updated context entries, leading to unpredictable behavior such as spurious page faults, memory access violations, or potential information leakage if sensitive data remains accessible through a mapping that software believes has been revoked.
The operational impact of this vulnerability can range from system instability to security compromises depending on the workload and timing conditions. In benign scenarios, it may manifest as transient I/O errors or device driver timeouts due to spurious faults generated by the hardware attempting to translate addresses using corrupted context entries. However, in more severe cases involving sensitive data handling or virtualization environments, this race condition could allow a guest operating system or malicious process to access memory regions that were intended to be unmapped. If an attacker can trigger rapid allocation and deallocation of IOMMU contexts while the hardware is fetching these partially torn entries, they might exploit the window where old mappings are still technically valid according to the hardware state but logically invalid in software. This aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization, as well as CWE-829, Inclusion of Functionality from Untrusted Control Sphere, if the stale mapping allows access to restricted memory regions. Furthermore, this behavior can be mapped to MITRE ATT&CK technique T1499, Endpoint Denial of Service, due to potential system crashes or device unresponsiveness caused by hardware faults.
To mitigate this vulnerability and restore correct synchronization between software state transitions and hardware visibility, the fix implements a strict ownership handshake as prescribed in the Intel VT-d specification Section 6.5.3.3 regarding guidance for invalidations. The corrected procedure mandates that when tearing down a context entry, the driver must first clear only the Present bit to signal intent to invalidate without immediately destroying all data fields. Following this single-bit modification, the system must ensure visibility of this change by flushing the specific cache line containing the context entry to main memory if necessary for non-coherent systems. Only after confirming that the hardware has observed the clearing of the Present bit should the driver issue the context-cache and IOTLB invalidation commands. Finally, once these invalidations are complete and acknowledged, the remainder of the 128-bit context entry can be safely zeroed out. This sequence ensures that the hardware never observes a partially torn entry with an active Present bit, thereby eliminating the race condition window and preventing spurious faults or unauthorized memory access resulting from stale mapping states.