Linux kernel maintainers disclosed CVE-2026-45894 on May 27, 2026, for an Intel VT-d IOMMU bug in which Linux could tear down an active PASID table entry in pieces, letting hardware briefly observe a corrupted translation state. The flaw is not a flashy remote-code-execution story, and NVD has not yet assigned a CVSS score. But it is exactly the kind of low-level virtualization defect that matters to people running Linux hosts, VFIO passthrough rigs, containerized accelerators, and mixed Windows-on-Linux lab environments. The fix is also a reminder that modern platform security is increasingly about choreography: not just what the kernel writes, but when hardware is allowed to see it.
CVE-2026-45894 is rooted in Intel VT-d Scalable Mode, the IOMMU architecture Linux uses to isolate and translate device DMA. In plain English, the IOMMU is the memory-management cop for devices: it decides which physical memory a PCIe device may read or write, and it is essential to device assignment, DMA protection, and modern virtualization.
The vulnerable object is a PASID entry. PASID, short for Process Address Space ID, lets devices tag DMA transactions so that different address spaces can be distinguished. That capability matters for accelerators, shared virtual memory, and more advanced virtualization paths where the old model of “one device, one translation domain” is too blunt.
The Linux bug was not that the kernel forgot to invalidate something entirely. It was subtler. When Linux tore down a PASID entry, it zeroed the full 64-byte entry with multiple 64-bit writes while the entry could still be marked present. Intel’s VT-d hardware, meanwhile, may fetch that same 64-byte structure through multiple internal transactions.
That creates the nightmare race condition: the CPU is dismantling a table entry one slice at a time while hardware is reading it one slice at a time. If those two operations overlap, the IOMMU can observe a hybrid object — half old, half new, and still apparently valid. Kernel developers call this a torn read, and in this context it can lead to unpredictable behavior or spurious DMA-remapping faults.
That does not make the issue irrelevant. Kernel CVEs often arrive before the tidy enterprise paperwork catches up, especially when the fix is already understood upstream. Here, the vulnerability description itself gives an unusually clear diagnosis: Linux was violating the invalidation guidance for VT-d by erasing an entry before first making the ownership transition unambiguous.
The patched behavior follows a more conservative handshake. Linux first clears only the Present bit, uses a DMA write memory barrier so hardware sees that change in the intended order, performs the required invalidations, and only then clears the remaining fields. On setup, the complementary rule is also enforced: make all the other PASID fields visible before setting the Present bit.
That distinction is the whole story. “Present” is not just another flag. It is the sign on the door telling the IOMMU whether the rest of the room is safe to enter.
This is the sort of discipline kernel developers spend years internalizing because the alternative is chaos that only appears under timing pressure. A PASID entry is not updated in a magical single operation. It is 512 bits long, and ordinary CPU stores cannot make the entire thing appear atomically to a device walker.
The old teardown path treated zeroing as if it were a clean deletion. The new path treats deletion as a negotiated state transition. That is more verbose, more careful, and exactly what hardware-software interfaces require when a structure can be observed asynchronously.
The added
A bug like this may show up less as a clean compromise and more as instability. Spurious DMAR faults, failed device assignment, odd accelerator behavior, or intermittent guest problems are the kind of symptoms administrators dread because they look like firmware, hardware, driver, and kernel issues all at once. The CVE description itself emphasizes unpredictable behavior and spurious faults rather than a neat exploit primitive.
That makes it operationally important even before the vulnerability databases finish their paperwork. In a home lab, the consequence may be a flaky passthrough setup. In an enterprise virtualization cluster, the consequence may be a hard-to-reproduce device assignment problem that appears only under teardown pressure. In a security-sensitive environment, anything that weakens confidence in DMA isolation deserves attention.
There is a useful caution here for Windows admins, too. Windows has its own DMA protection stack and its own relationship with IOMMU hardware, but the underlying hardware lesson is shared: device isolation is not a toggle. It is a protocol implemented across firmware, silicon, OS kernels, drivers, and invalidation machinery.
That extra power expands the number of states the OS and hardware must coordinate. A traditional DMA remapping setup already has root tables, context tables, IOTLBs, device TLBs, and invalidation queues. Scalable Mode adds larger entries and richer translation types. PASID brings per-process or per-address-space identity into the mix.
Every one of those additions improves performance or flexibility, but also creates more opportunities for races if the teardown path is treated as an afterthought. In security engineering, deletion is often harder than creation. Setup can be staged in private and made visible at the end. Teardown happens while something else may still be looking.
That is why the fix’s sequencing is so revealing. It does not merely change a field value. It changes the relationship between software and hardware by making Present the boundary between a live translation object and a dead one.
It is not bookkeeping. It is an encoded hardware contract.
The kernel’s IOMMU code has to assume that devices and remapping hardware are not passive observers. They cache, prefetch, pipeline, and walk tables independently. They may see memory at moments that ordinary application developers never have to reason about. The driver’s job is not simply to maintain a correct data structure in the abstract; it must maintain a correct data structure under concurrent hardware observation.
That is why CVE-2026-45894 is a useful case study. The fix does not require Linux to abandon PASID or disable Scalable Mode. It requires the teardown path to respect the same atomicity expectations the architecture imposes elsewhere. It is an incremental correction to a precise race window, not a repudiation of the technology.
But narrow does not mean trivial. The affected code sits in a privileged path that arbitrates device access to memory. If it misbehaves, the failure mode is below the level of ordinary process isolation. That is precisely why IOMMU defects matter: they live at a boundary most software assumes is already settled.
The most exposed users are likely those exercising Intel VT-d Scalable Mode and PASID paths heavily. That can include virtualization hosts with device passthrough, systems using Shared Virtual Memory-style capabilities, accelerator-heavy workloads, and kernels tracking newer IOMMU features. Desktop Linux users with no such configuration may still receive the patch, but the practical likelihood of encountering the race is likely lower.
Enterprises should treat the absence of an NVD score as a temporary information gap, not as proof of no risk. The rational response is to identify whether affected kernels are deployed in environments where device assignment and PASID-capable hardware matter, then plan kernel updates according to existing maintenance windows unless local exposure or instability argues for faster action.
Those configurations lean heavily on the IOMMU. The promise of passthrough is that a guest can talk to hardware at near-native speed without gaining uncontrolled access to host memory. When the IOMMU layer mismanages an entry, even briefly, the resulting failures can look like guest driver bugs or PCIe weirdness rather than a host-kernel race.
This is also why forum troubleshooting around DMAR faults can be so maddening. A line in
CVE-2026-45894 will not explain every passthrough failure. But it is a reminder that when a system depends on precise DMA-remapping semantics, kernel point releases can contain fixes that materially improve reliability even if the changelog reads like dense architecture prose.
This creates a practical problem for defenders. Patch dashboards tend to prioritize numbers. If there is no score, the item can drift below the line even when the underlying subsystem is important. Conversely, once a score appears, the same issue may suddenly become urgent without any new technical facts.
A better approach is to read the subsystem. IOMMU code is security-relevant because it controls DMA isolation. VT-d Scalable Mode and PASID are advanced features that matter in virtualization and accelerator scenarios. The described failure mode is a race that can produce inconsistent hardware-visible state. Those facts are enough to justify tracking the fix.
The lack of a score should shape communication, not action. Administrators can say there is no public severity rating yet, no public evidence of exploitation in the record, and no reason for theatrical mitigations. They can also say affected kernels should be updated, especially on hosts where Intel VT-d and PASID-capable device workflows are in use.
The corrected sequence is slower in the way correctness is sometimes slower. It introduces a stricter ordering point and requires invalidations before the final cleanup. But that cost is the price of making the hardware/software boundary deterministic.
For most users, the performance difference should be invisible. PASID teardown is not the hot loop of a game frame or a database query. The real gain is not speed but confidence: after the Present bit is cleared and the right flushes complete, the kernel can safely reuse or erase the entry without gambling on what the IOMMU may still be fetching.
This is the kernel engineering tradeoff at its best. No branding campaign, no big feature flag, no security theater — just a fix that makes the machine obey the architecture more faithfully.
This is especially relevant for Proxmox-style hosts, KVM boxes, VFIO workstations, and servers using device assignment or PASID-aware hardware. If those systems are already showing unexplained DMAR faults during device attach, detach, guest shutdown, or workload teardown, this CVE belongs on the shortlist of possible kernel-side contributors.
Administrators should also resist the urge to “fix” the issue by blindly disabling IOMMU features without understanding the tradeoff. Turning off VT-d or DMA remapping may reduce exposure to this specific code path, but it can also remove important isolation guarantees and break virtualization workflows. In most managed environments, updating the kernel is the cleaner answer.
The right posture is boring and disciplined: inventory affected Linux hosts, prioritize virtualization and accelerator systems, test the updated kernel against passthrough workloads, and roll forward. If the platform is a production Windows virtualization host built on Linux, treat it as infrastructure, not as a hobby box with a changelog.
The Bug Lives in the Space Between a CPU Store and a Device Fetch
CVE-2026-45894 is rooted in Intel VT-d Scalable Mode, the IOMMU architecture Linux uses to isolate and translate device DMA. In plain English, the IOMMU is the memory-management cop for devices: it decides which physical memory a PCIe device may read or write, and it is essential to device assignment, DMA protection, and modern virtualization.The vulnerable object is a PASID entry. PASID, short for Process Address Space ID, lets devices tag DMA transactions so that different address spaces can be distinguished. That capability matters for accelerators, shared virtual memory, and more advanced virtualization paths where the old model of “one device, one translation domain” is too blunt.
The Linux bug was not that the kernel forgot to invalidate something entirely. It was subtler. When Linux tore down a PASID entry, it zeroed the full 64-byte entry with multiple 64-bit writes while the entry could still be marked present. Intel’s VT-d hardware, meanwhile, may fetch that same 64-byte structure through multiple internal transactions.
That creates the nightmare race condition: the CPU is dismantling a table entry one slice at a time while hardware is reading it one slice at a time. If those two operations overlap, the IOMMU can observe a hybrid object — half old, half new, and still apparently valid. Kernel developers call this a torn read, and in this context it can lead to unpredictable behavior or spurious DMA-remapping faults.
This Is a Kernel Memory-Ordering Story, Not a Patch-Tuesday Panic
The important thing to understand about CVE-2026-45894 is that it is not described as an easy attacker-controlled exploit. The public record, at the time of publication, does not include an NVD score, a complete CVSS vector, or evidence of active exploitation. NVD has marked the record as awaiting enrichment, which means administrators are still dealing with a kernel.org-originated vulnerability entry rather than a fully scored risk package.That does not make the issue irrelevant. Kernel CVEs often arrive before the tidy enterprise paperwork catches up, especially when the fix is already understood upstream. Here, the vulnerability description itself gives an unusually clear diagnosis: Linux was violating the invalidation guidance for VT-d by erasing an entry before first making the ownership transition unambiguous.
The patched behavior follows a more conservative handshake. Linux first clears only the Present bit, uses a DMA write memory barrier so hardware sees that change in the intended order, performs the required invalidations, and only then clears the remaining fields. On setup, the complementary rule is also enforced: make all the other PASID fields visible before setting the Present bit.
That distinction is the whole story. “Present” is not just another flag. It is the sign on the door telling the IOMMU whether the rest of the room is safe to enter.
The Present Bit Becomes the Contract
The CVE description points to Intel’s “Guidance to Software for Invalidations,” and the fix tracks the logic of a classic ownership protocol. Software must not remodel a structure while hardware is still permitted to treat it as live. First revoke ownership. Then make sure the revocation is visible. Then flush cached references. Then clean up the room.This is the sort of discipline kernel developers spend years internalizing because the alternative is chaos that only appears under timing pressure. A PASID entry is not updated in a magical single operation. It is 512 bits long, and ordinary CPU stores cannot make the entire thing appear atomically to a device walker.
The old teardown path treated zeroing as if it were a clean deletion. The new path treats deletion as a negotiated state transition. That is more verbose, more careful, and exactly what hardware-software interfaces require when a structure can be observed asynchronously.
The added
dma_wmb() calls matter because ordinary code order is not always device-visible order. A CPU may execute stores in one sequence, caches and interconnects may expose them differently, and hardware table walkers do not share the programmer’s mental model unless the kernel imposes one. The barrier is the kernel saying: this visibility boundary is real.Why Virtualization Hosts Should Care Even Without a High CVSS Score
For WindowsForum readers, the obvious question is why a Linux IOMMU bug belongs in the same conversation as Windows desktops and servers. The answer is that a large amount of Windows testing, gaming, development, and infrastructure now rides on Linux virtualization hosts. Proxmox, KVM, VFIO, GPU passthrough, Windows guests, nested labs, and workstation hypervisors all sit near this code path when Intel VT-d and PASID-capable devices enter the picture.A bug like this may show up less as a clean compromise and more as instability. Spurious DMAR faults, failed device assignment, odd accelerator behavior, or intermittent guest problems are the kind of symptoms administrators dread because they look like firmware, hardware, driver, and kernel issues all at once. The CVE description itself emphasizes unpredictable behavior and spurious faults rather than a neat exploit primitive.
That makes it operationally important even before the vulnerability databases finish their paperwork. In a home lab, the consequence may be a flaky passthrough setup. In an enterprise virtualization cluster, the consequence may be a hard-to-reproduce device assignment problem that appears only under teardown pressure. In a security-sensitive environment, anything that weakens confidence in DMA isolation deserves attention.
There is a useful caution here for Windows admins, too. Windows has its own DMA protection stack and its own relationship with IOMMU hardware, but the underlying hardware lesson is shared: device isolation is not a toggle. It is a protocol implemented across firmware, silicon, OS kernels, drivers, and invalidation machinery.
PASID Makes Device Isolation More Powerful and More Fragile
PASID exists because the old I/O model was not enough. Modern devices are smarter, more parallel, and more tightly integrated into application memory. GPUs, AI accelerators, NVMe devices, and high-performance networking hardware increasingly need fine-grained identity and address-space separation.That extra power expands the number of states the OS and hardware must coordinate. A traditional DMA remapping setup already has root tables, context tables, IOTLBs, device TLBs, and invalidation queues. Scalable Mode adds larger entries and richer translation types. PASID brings per-process or per-address-space identity into the mix.
Every one of those additions improves performance or flexibility, but also creates more opportunities for races if the teardown path is treated as an afterthought. In security engineering, deletion is often harder than creation. Setup can be staged in private and made visible at the end. Teardown happens while something else may still be looking.
That is why the fix’s sequencing is so revealing. It does not merely change a field value. It changes the relationship between software and hardware by making Present the boundary between a live translation object and a dead one.
The Patch Is Small Because the Contract Is Big
One reason low-level kernel bugs can be underestimated is that the patch often looks unremarkable. Add a barrier. Clear a bit earlier. Move zeroing later. Flush the right caches in the right order. To a casual reader, that can look like bookkeeping.It is not bookkeeping. It is an encoded hardware contract.
The kernel’s IOMMU code has to assume that devices and remapping hardware are not passive observers. They cache, prefetch, pipeline, and walk tables independently. They may see memory at moments that ordinary application developers never have to reason about. The driver’s job is not simply to maintain a correct data structure in the abstract; it must maintain a correct data structure under concurrent hardware observation.
That is why CVE-2026-45894 is a useful case study. The fix does not require Linux to abandon PASID or disable Scalable Mode. It requires the teardown path to respect the same atomicity expectations the architecture imposes elsewhere. It is an incremental correction to a precise race window, not a repudiation of the technology.
The Risk Is Narrow, but the Blast Radius Is Modern
This CVE should not be oversold. The currently available public information does not justify panic, broad claims of remote exploitation, or advice to disable Intel virtualization features across the board. For many users, the fix will arrive as part of a normal kernel update and never be noticed.But narrow does not mean trivial. The affected code sits in a privileged path that arbitrates device access to memory. If it misbehaves, the failure mode is below the level of ordinary process isolation. That is precisely why IOMMU defects matter: they live at a boundary most software assumes is already settled.
The most exposed users are likely those exercising Intel VT-d Scalable Mode and PASID paths heavily. That can include virtualization hosts with device passthrough, systems using Shared Virtual Memory-style capabilities, accelerator-heavy workloads, and kernels tracking newer IOMMU features. Desktop Linux users with no such configuration may still receive the patch, but the practical likelihood of encountering the race is likely lower.
Enterprises should treat the absence of an NVD score as a temporary information gap, not as proof of no risk. The rational response is to identify whether affected kernels are deployed in environments where device assignment and PASID-capable hardware matter, then plan kernel updates according to existing maintenance windows unless local exposure or instability argues for faster action.
The Windows Angle Is the Linux Host Under the Desk
For Windows enthusiasts, this bug intersects with a familiar modern setup: a Windows guest running on a Linux host with PCIe devices passed through. That may be a gaming VM with a GPU, a test lab with assigned NICs, or a development workstation using Linux as the bare-metal control plane while Windows handles vendor tools, games, or legacy applications.Those configurations lean heavily on the IOMMU. The promise of passthrough is that a guest can talk to hardware at near-native speed without gaining uncontrolled access to host memory. When the IOMMU layer mismanages an entry, even briefly, the resulting failures can look like guest driver bugs or PCIe weirdness rather than a host-kernel race.
This is also why forum troubleshooting around DMAR faults can be so maddening. A line in
dmesg about a present bit, a PASID, or an IOTLB invalidation does not map neatly to a single consumer-friendly fix. It may involve kernel version, firmware settings, platform errata, device behavior, and timing.CVE-2026-45894 will not explain every passthrough failure. But it is a reminder that when a system depends on precise DMA-remapping semantics, kernel point releases can contain fixes that materially improve reliability even if the changelog reads like dense architecture prose.
The Security Databases Are Lagging the Engineering Reality
The NVD entry for CVE-2026-45894 currently says the record is awaiting enrichment, with no NVD-provided CVSS 4.0, 3.x, or 2.0 score. That is not unusual for fresh kernel CVEs, especially ones that come directly from the Linux kernel CNA stream and reference stable commits before broader scoring analysis is complete.This creates a practical problem for defenders. Patch dashboards tend to prioritize numbers. If there is no score, the item can drift below the line even when the underlying subsystem is important. Conversely, once a score appears, the same issue may suddenly become urgent without any new technical facts.
A better approach is to read the subsystem. IOMMU code is security-relevant because it controls DMA isolation. VT-d Scalable Mode and PASID are advanced features that matter in virtualization and accelerator scenarios. The described failure mode is a race that can produce inconsistent hardware-visible state. Those facts are enough to justify tracking the fix.
The lack of a score should shape communication, not action. Administrators can say there is no public severity rating yet, no public evidence of exploitation in the record, and no reason for theatrical mitigations. They can also say affected kernels should be updated, especially on hosts where Intel VT-d and PASID-capable device workflows are in use.
The Fix Favors Boring Correctness Over Clever Speed
There is a tempting performance instinct in low-level code: if an object is going away, just zero it and move on. That instinct works until the object is shared with a piece of hardware that has its own timing, caches, and walkers. CVE-2026-45894 is what happens when deletion is treated as a write pattern rather than a state machine.The corrected sequence is slower in the way correctness is sometimes slower. It introduces a stricter ordering point and requires invalidations before the final cleanup. But that cost is the price of making the hardware/software boundary deterministic.
For most users, the performance difference should be invisible. PASID teardown is not the hot loop of a game frame or a database query. The real gain is not speed but confidence: after the Present bit is cleared and the right flushes complete, the kernel can safely reuse or erase the entry without gambling on what the IOMMU may still be fetching.
This is the kernel engineering tradeoff at its best. No branding campaign, no big feature flag, no security theater — just a fix that makes the machine obey the architecture more faithfully.
The Practical Read for Admins Running Intel VT-d Hosts
The operational path is straightforward, even if the underlying bug is not. Linux users should watch their distribution’s kernel advisories and stable kernel updates for the backported fix. Those running self-built kernels should check whether their chosen stable branch includes one of the referenced upstream stable commits.This is especially relevant for Proxmox-style hosts, KVM boxes, VFIO workstations, and servers using device assignment or PASID-aware hardware. If those systems are already showing unexplained DMAR faults during device attach, detach, guest shutdown, or workload teardown, this CVE belongs on the shortlist of possible kernel-side contributors.
Administrators should also resist the urge to “fix” the issue by blindly disabling IOMMU features without understanding the tradeoff. Turning off VT-d or DMA remapping may reduce exposure to this specific code path, but it can also remove important isolation guarantees and break virtualization workflows. In most managed environments, updating the kernel is the cleaner answer.
The right posture is boring and disciplined: inventory affected Linux hosts, prioritize virtualization and accelerator systems, test the updated kernel against passthrough workloads, and roll forward. If the platform is a production Windows virtualization host built on Linux, treat it as infrastructure, not as a hobby box with a changelog.
The Present Bit Is the Part to Remember
The concrete lessons from CVE-2026-45894 are narrow enough to be useful and broad enough to outlive this one patch. This is not a headline-grabbing bug, but it touches the machinery that makes modern device isolation credible.- Linux received a kernel fix for CVE-2026-45894 after maintainers identified a race in Intel VT-d PASID entry teardown.
- The vulnerable behavior involved clearing a 64-byte PASID entry while hardware could still see the entry as present.
- The corrected sequence clears the Present bit first, enforces DMA-visible ordering, performs the required invalidations, and only then clears the rest of the entry.
- The issue is most relevant to systems using Intel VT-d Scalable Mode, PASID-capable hardware, virtualization, device passthrough, or accelerator workflows.
- NVD had not assigned a severity score at the time of publication, so administrators should evaluate exposure by subsystem importance rather than waiting for a dashboard number.
- For most users, the expected remedy is a kernel update from their distribution or stable kernel branch rather than a disruptive configuration change.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-28T01:04:10-07:00
NVD - CVE-2026-45894
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-28T01:04:10-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: spinics.net
[PATCH 6/7] iommu/vt-d: Clear Present bit before tearing down context entry — Linux Kernel
Linux Kernel: [PATCH 6/7] iommu/vt-d: Clear Present bit before tearing down context entry
www.spinics.net
- Related coverage: patchew.org
- Related coverage: intel.cn
- Related coverage: minzkn.com
IOMMU (Input-Output Memory Management Unit)
Linux 커널 IOMMU 서브시스템 — Intel VT-d, AMD-Vi, ARM SMMU, DMA remapping, interrupt remapping, PASID, SVA 가이드.
www.minzkn.com
- Related coverage: git.zx2c4.com
