CVE-2026-80894 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Fix wrong hwpt passed to iommufd_auto_response_faults on replace
iommufd_hwpt_replace_device() calls:
iommufd_auto_response_faults(hwpt, old_handle);
passing the *new* hwpt together with the handle of the device's *old* domain. This should be a parameter mismatch:
1. Semantically, iommufd_auto_response_faults(x, handle) scans x->fault's deliver list and response xarray for groups matching "handle". A group is queued under the hwpt that was attached at fault-delivery time. old_handle is fetched *before* the domain switch, so its group lives on old->fault, not on the new hwpt->fault.
2. Historically, the first argument was "old". The routine was introduced by commit b7d8833677ba ("iommufd: Fault-capable hwpt attach/detach/replace") as __fault_domain_replace_dev() in fault.c, correctly calling iommufd_auto_response_faults(old, curr). Commit fb21b1568ada ("iommufd: Make attach_handle generic than fault specific") moved this into iommufd_hwpt_replace_device() in device.c and swapped it to "hwpt". This should be a refactor regression, not an intentional change.
Fix this by passing "old" instead.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel's IOMMUFD subsystem contains a critical logic error within the hardware page table replacement mechanism that compromises the integrity of fault handling during device domain transitions. Specifically, in the function iommufd_hwpt_replace_device, there is an incorrect parameter passed to the internal routine iommufd_auto_response_faults. The code erroneously passes the new hardware page table pointer as the first argument while simultaneously passing the handle associated with the old IOMMU domain as the second argument. This mismatch creates a fundamental disconnect between the data structure being scanned and the context in which faults were originally recorded, leading to potential failures in processing pending or ongoing DMA fault events during device reconfiguration.
The technical root of this vulnerability lies in how the iommufd_auto_response_faults function operates. This routine is designed to scan the fault delivery list and response address resolution array for groups that match a specific handle provided as an argument. Crucially, IOMMU groups are queued under the hardware page table context that was active at the time of fault delivery. Because the old_handle variable captures the identifier of the device's previous domain before the switch occurs, it logically corresponds to faults recorded against the old hardware page table structure. By passing the new hwpt pointer as the first argument, the system attempts to search for groups within a data structure that does not contain those specific fault records. Consequently, any pending faults associated with the transition period may be ignored or mishandled because they are located in the old context but searched for in the new one.
This defect represents a regression introduced during a refactoring effort aimed at generalizing attach handles beyond just fault-specific operations. Originally, the routine was implemented as __fault_domain_replace_dev within fault.c and correctly invoked iommufd_auto_response_faults with the old hardware page table pointer alongside the current handle. When this logic was moved to device.c in the function iommufd_hwpt_replace_device, a parameter swap occurred that altered the semantic meaning of the arguments without adjusting the underlying data flow expectations. This oversight indicates that the refactoring process failed to account for the strict dependency between the hardware page table context and the fault group queueing mechanism, resulting in an unintentional change in behavior rather than a deliberate design decision.
The operational impact of this vulnerability can vary depending on system configuration but generally involves degraded reliability during dynamic IOMMU domain changes. In systems where devices are frequently reassigned or hot-plugged, such as virtualized environments using VFIO, the failure to correctly process faults from the old context could lead to stalled DMA transactions, incorrect error reporting, or potential data corruption if fault handling is bypassed entirely. While immediate system crashes may not always occur due to defensive coding elsewhere in the kernel, the lack of proper fault resolution undermines the guarantees provided by the IOMMU regarding memory protection and device isolation. This can result in subtle bugs that are difficult to reproduce but pose significant risks to data integrity and security posture over time.
From a classification perspective, this issue aligns with CWE-823, which covers use of outdated or incorrect variables, as well as CWE-691 regarding improper control flow transitions during state changes. In the context of MITRE ATT&CK, this type of logic error in kernel subsystems can be leveraged to bypass security controls related to device isolation and memory protection, potentially facilitating lateral movement or privilege escalation if an attacker can trigger repeated domain replacements under specific timing conditions. The vulnerability highlights the importance of rigorous code review during refactoring tasks that touch critical infrastructure components like IOMMU management interfaces.
To mitigate this risk, developers must ensure that iommufd_hwpt_replace_device passes the old hardware page table pointer to iommufd_auto_response_faults instead of the new one. This correction restores the semantic alignment between the fault records and their corresponding context structures. Additionally, implementing automated regression tests for device replacement scenarios would help prevent similar logical errors in future updates. System administrators should monitor kernel logs for unexpected IOMMU faults during device reconfiguration events as a heuristic indicator that this vulnerability may be present if patches have not yet been applied.