CVE-2026-80894

iommufd: Fix wrong hwpt passed to iommufd_auto_response_faults on replace

N/A
Published: September 4, 2026 at 05:11 PM UTC
Updated: September 4, 2026 at 06:36 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
N/A
Exploit prediction
EPSS 0.2%

Description

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

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v ≥ 6.13.12v ≥ 6.14.36.12.24 ≤ v < 6.12.1056.13.12 ≤ v < 6.146.14.3 ≤ v < 6.156.15 ≤ v < 6.18.446.15 ≤ v < 7.1.86.15 ≤ v < 7.21e0216b6a58c79b5ee91c78706d5f560e4d1f56f4b23c4b991eb90cc7bca42e9f81142feedd4bb566.12.246.13.126.14.36.156d11543bf37abdf60b8e6022a62fccfb82a5fe2efb21b1568adaa76af7a8c853f37c60fba8b28661
Vendor states this is fixed in 564ac339c0f8bada4e77a57a92bab9d3df635e07 (fixed)
Vendor states this is fixed in 8eb077025279304268bd58657f0af3d388822b21 (fixed)
Vendor states this is fixed in adb87155b67f9759ff010c0a99559f5bffa45dcf (fixed)
Vendor states this is fixed in ba5c0f28a26e7d9be1e0997f8920dd638e2782fd (fixed)
Vendor states this is fixed in 6.12.105 (unaffected)
Affected range stops below 6.14, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 6.15 (unaffected)
Vendor states this is fixed in 6.18.44 (unaffected)
Vendor states this is fixed in 7.1.8 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card