Answer in brief
CVE-2026-45945 records a Unknown severity vulnerability in iommu/vt-d: Fix race condition during PASID entry replacement. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=7543ee63e8113aa34b07df3b16b3b9d2c5f73939 <4718007870547e1efebbdd6745d9fce58f008fef || >=7543ee63e8113aa34b07df3b16b3b9d2c5f73939 <66a7aff480a82b8642b3991fed5fdc9780022157 || >=7543ee63e8113aa34b07df3b16b3b9d2c5f73939 <c3b1edea3791fa91ab7032faa90355913ad9451b | 4718007870547e1efebbdd6745d9fce58f008fef, 66a7aff480a82b8642b3991fed5fdc9780022157, c3b1edea3791fa91ab7032faa90355913ad9451b |
| Linux/Linuxgeneric | 6.13 | Not reported |
Published upstream
May 27, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
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.
Quoted source text, attributed separately from HOL analysis.