CVE-2026-45945: iommu/vt-d: Fix race condition during PASID entry replacement
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix race condition during PASID entry replacement
The Intel VT-d PASID table entry is 512 bits (64 bytes). When replacing
an active PASID entry (e.g., during domain replacement), the current
implementation calculates a new entry on the stack and copies it to the
table using a single structure assignment.
struct pasid_entry *pte, new_pte;
pte = intel_pasid_get_entry(dev, pasid);
pasid_pte_config_first_level(iommu, &new_pte, ...);
*pte = new_pte;
Because the hardware may fetch the 512-bit PASID entry in multiple
128-bit chunks, updating the entire entry while it is active (Present
bit set) risks a "torn" read. In this scenario, the IOMMU hardware
could observe an inconsistent state โ partially new data and partially
old data โ leading to unpredictable behavior or spurious faults.
Fix this by removing the unsafe "replace" helpers and following the
"clear-then-update" flow, which ensures the Present bit is cleared and
the required invalidation handshake is completed before the new
configuration is applied.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue affects Intel VT-d IOMMU handling. A local user or workload could trigger a race while the kernel replaces an active PASID entry, causing the hardware to see mixed old and new data. The stated risk is high because kernel/IOMMU corruption can affect confidentiality, integrity, and availability, but public sources do not report active exploitation.
Executive priority
Treat as a high-priority kernel maintenance item for Linux fleets using Intel VT-d. It is not currently described as exploited in the provided sources, but the impact rating is high and the fix is kernel-level. Prioritize critical hosts, virtualization infrastructure, and systems running untrusted local workloads.
Technical view
The flaw is a race in iommu/vt-d PASID entry replacement. A 512-bit PASID table entry was assigned while still present; hardware may fetch it in 128-bit chunks and observe a torn entry. The fix changes replacement to a clear-then-update flow with invalidation before applying new configuration. CVSS is 8.8: AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.
Likely exposure
Systems are most relevant if they run affected Linux kernel versions with Intel VT-d/IOMMU and PASID-capable device paths. The source lists Linux as affected across versions including 6.13, 6.18.39, 6.19.4, and 7.0, but the version data is not fully clear. Validate against kernel stable commits and vendor advisories.
Exploitation context
The CVSS vector requires local access with low privileges and no user interaction. Sources describe unpredictable behavior or spurious faults from inconsistent IOMMU state. No KEV listing is present, and the provided sources do not state that exploitation is active or that public exploit code exists.
Researcher notes
Evidence is limited to the CVE record and upstream stable commit references. The root cause is a torn hardware read during active PASID entry replacement. Avoid assuming exploitability beyond the local, low-privilege CVSS vector. Confirm exact affected and fixed kernel ranges from distro backports, because the provided affected-version data appears inconsistent.
Mitigation direction
Review your distribution or kernel vendor advisory for CVE-2026-45945.
Update to a kernel containing the referenced stable fixes.
Prioritize hosts using Intel VT-d/IOMMU and PASID-capable devices.
If patching is delayed, monitor vendor guidance for supported mitigations.
Validation and detection
Inventory Linux kernel versions across physical hosts and virtualization platforms.
Check whether Intel VT-d/IOMMU features are enabled on exposed systems.
Map installed kernels to the referenced upstream stable commits.
Review kernel logs for IOMMU or PASID-related faults after updates.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve ยท low confidence lookup
CVE-2026-45945 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
4Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.