CVE-2026-80894
NoneCVSS
—
EPSS
0.2%
Published
Sep 4, 2026
CISA due date
—
Cloudanix analysis
A coding mistake in the Linux kernel's device memory management can cause faults to be handled incorrectly when switching between different memory setups for hardware devices.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Theoretical
- Impact
- Other
- Component
- OS kernel
- Class
- Other
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The flaw passes the new hwpt to iommufd_auto_response_faults during iommufd_hwpt_replace_device instead of the old hwpt, so fault groups queued under the prior domain are never matched or responded to correctly.
Why it matters to the business
Kernel builds with IOMMU fault-capable devices may experience incomplete fault handling during live domain switches, increasing risk of device isolation failures or unexpected behavior in virtualized and container workloads.
How an attack unfolds
An attacker with the ability to trigger repeated attach/replace operations on a fault-capable IOMMU device can cause the kernel to consult the wrong fault list, leaving prior-domain faults unhandled and potentially allowing stale mappings to persist.
How to fix it
Apply the upstream fix that restores the original 'old' hwpt argument to iommufd_auto_response_faults; rebuild and deploy the corrected kernel image to all affected systems.
How to confirm the fix worked
Confirm the corrected call site in device.c matches the original semantics from fault.c; exercise domain replace paths under fault load and verify all queued faults receive responses.
Typical attack path
- Obtain capability to attach and replace IOMMU domains on a fault-capable device
- Trigger iommufd_hwpt_replace_device while faults are queued under the old handle
- Observe that iommufd_auto_response_faults operates on the new hwpt instead of the old one
- Exploit the resulting mismatch to bypass intended fault responses or retain unauthorized mappings
How to detect it
Inspect kernel logs and IOMMU fault traces around domain replace events for signs that faults queued under an old handle were never responded to; correlate with attach/replace audit records.
What your security team should do
- Prioritize kernel update on systems exposing IOMMU fault-capable devices to untrusted guests or containers
- Monitor kernel changelogs for iommufd patches and schedule staged rollouts within standard maintenance windows
- Review IOMMU usage in virtualization and container platforms to identify high-value targets for early patching
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|