CVE-2026-89445

What it actually does

A use-after-free in the Linux kernel IOMMUFD selftest IOPF-reporting path lets a concurrent PASID detach free an attach handle while iommu_report_device_fault() still borrows that handle and its domain pointer. TRIGGER_IOPF then dereferences the freed iommufd_attach_handle, corrupting kernel memory. On hosts where the mock/selftest driver is present, this can yield kernel crash, information disclosure, or privilege escalation beyond the attacking process (changed scope; high confidentiality, integrity, and availability impact).

Why it matters to the business

Risk is local-only and concentrated on systems that ship or load IOMMUFD selftest/mock code rather than typical production IOMMUFD. CVSS is high (8.8), but likelihood is low: EPSS about 0.00175 with a flat 30-day trend, not in CISA KEV, not tied to ransomware, and no public exploit maturity about 31 days after publication. If the test infrastructure is enabled, a successful exploit could fully compromise the host and any co-located workloads. Treat as standard kernel-patching priority unless selftest modules are loaded in production, in which case escalate.

How an attack unfolds

A local, low-privileged user who can exercise the IOMMUFD selftest TRIGGER_IOPF path races it against PASID detach. The selftest borrows an attach handle from the group's PASID array without synchronizing against detach, so a concurrent fault report can use the handle after it is erased and the backing iommufd_attach_handle is freed. Winning that race produces a kernel use-after-free that can be abused for memory corruption, host crash, or privilege gain. No named threat actors, campaigns, or ransomware use are associated with this issue, and no public exploit is reported.

How to fix it

Apply vendor or upstream Linux kernel updates that fix IOMMUFD selftest IOPF reporting by adding an iopf_rwsem on the mock device: hold the read side across the full iommu_report_device_fault() call and the write side around attach, detach, domain replace, and mock-device registration so in-flight reports drain before handles are removed. Exact patched package versions were not supplied; follow your distribution's kernel advisory. Until patched, do not load IOMMUFD selftest/mock modules on production hosts and disable related test kernel configs (for example IOMMUFD test/mock builds) so TRIGGER_IOPF and mock attach paths are unavailable.

How to confirm the fix worked

Confirm the running kernel changelog or distro advisory includes the iommufd selftest IOPF UAF fix (iopf_rwsem around fault report and domain attach/detach/replace). Verify IOMMUFD test/mock modules are not loaded and that production kernels were not built with IOMMUFD selftest options enabled. After patching, reboot into the new kernel and confirm uname/package version matches the advisory. On still-vulnerable kernels, treat presence of the selftest/mock driver as exposure even without a crash.

Typical attack path

1. Gain local access with a low-privileged account on a host where IOMMUFD selftest/mock code is available
2. Exercise the selftest IOPF reporting path while a PASID attach handle is live
3. Race that report against PASID detach or domain replace so the borrowed handle is freed
4. Cause the kernel to dereference the freed attach handle and domain pointer
5. Turn the resulting use-after-free into kernel memory corruption, denial of service, or elevated privileges

How to detect it

This is a local kernel race with no network signature and no public exploit, so look for post-crash artifacts rather than inbound traffic. Review dmesg, journal, and crash dumps around iommu_report_device_fault, iommufd attach-handle teardown, mock device, and IOPF reporting. Hunt for KASAN or KFENCE use-after-free reports against iommufd_attach_handle, unexpected loading of IOMMUFD selftest/mock modules, and oops/panic with RIP in IOMMUFD or mock-driver fault paths. Correlate with local processes that opened the IOMMUFD device around the same time. Absence of these artifacts does not prove non-exploitation if the host was rebooted without persistent logs.

• KASAN: use-after-free
• iommufd_attach_handle
• iommu_report_device_fault
• TRIGGER_IOPF
• iommufd_test
• mock_dev
• Unable to handle kernel paging request
• RIP:.*iommufd
• /dev/iommu

What your security team should do

• Inventory hosts for IOMMUFD selftest/mock modules or test-enabled kernel builds and treat those as in-scope
• Patch and reboot to a kernel that includes the iopf_rwsem selftest fix per distro guidance
• Block loading of IOMMUFD test/mock modules on production images until patched
• Prioritize multi-tenant and privileged-workload hosts if the test path is present; otherwise follow normal kernel cadence given low EPSS and no KEV listing
• Watch kernel logs for iommufd/IOPF-related oops or KASAN use-after-free reports during the 31-day window since publication