GHSA-XP3W-6F4F-GVG7

Vulnerability from github – Published: 2026-05-27 15:33 – Updated: 2026-05-27 15:33
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Clear Present bit before tearing down context entry

When tearing down a context entry, the current implementation zeros the entire 128-bit entry using multiple 64-bit writes. This creates a window where the hardware can fetch a "torn" entry — where some fields are already zeroed while the 'Present' bit is still set — leading to unpredictable behavior or spurious faults.

While x86 provides strong write ordering, the compiler may reorder writes to the two 64-bit halves of the context entry. Even without compiler reordering, the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes.

Align with the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

  1. Clear only the 'Present' (P) bit of the context entry first to signal the transition of ownership from hardware to software.
  2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.
  3. Perform the required cache and context-cache invalidation to ensure hardware no longer has cached references to the entry.
  4. Fully zero out the entry only after the invalidation is complete.

Also, add a dma_wmb() to context_set_present() to ensure the entry is fully initialized before the 'Present' bit becomes visible.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-45944"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-27T14:17:10Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clear Present bit before tearing down context entry\n\nWhen tearing down a context entry, the current implementation zeros the\nentire 128-bit entry using multiple 64-bit writes. This creates a window\nwhere the hardware can fetch a \"torn\" entry \u2014 where some fields are\nalready zeroed while the \u0027Present\u0027 bit is still set \u2014 leading to\nunpredictable behavior or spurious faults.\n\nWhile x86 provides strong write ordering, the compiler may reorder writes\nto the two 64-bit halves of the context entry. Even without compiler\nreordering, the hardware fetch is not guaranteed to be atomic with\nrespect to multiple CPU writes.\n\nAlign with the \"Guidance to Software for Invalidations\" in the VT-d spec\n(Section 6.5.3.3) by implementing the recommended ownership handshake:\n\n1. Clear only the \u0027Present\u0027 (P) bit of the context entry first to\n   signal the transition of ownership from hardware to software.\n2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.\n3. Perform the required cache and context-cache invalidation to ensure\n   hardware no longer has cached references to the entry.\n4. Fully zero out the entry only after the invalidation is complete.\n\nAlso, add a dma_wmb() to context_set_present() to ensure the entry\nis fully initialized before the \u0027Present\u0027 bit becomes visible.",
  "id": "GHSA-xp3w-6f4f-gvg7",
  "modified": "2026-05-27T15:33:17Z",
  "published": "2026-05-27T15:33:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45944"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a922dbafb4a674d958d702038232d09a30daf770"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c1e4f1dccbe9d7656d1c6872ebeadb5992d0aaa2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d2138abc8f0a7fce4101b7229b43b06811ed083d"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.