CVE-2026-89445

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

The UAF is reached only via local ioctls on /dev/iommu (or VFIO-compat /dev/vfio/vfio): IOMMU_TEST_CMD TRIGGER_IOPF calls iommu_report_device_fault() while a concurrent PASID/RID detach frees the attach handle. No network or packet-receive path exists.

AC:LAttack complexity, low

The attacker controls both sides of the race by issuing concurrent IOMMU_TEST_OP_TRIGGER_IOPF and PASID_DETACH/REPLACE or mock-domain destroy on the same fd; iommu_attach_handle_get() does not keep the handle alive after lookup, so no victim timing or uncontrollable layout is required.

PR:LPrivileges required, low

iommufd_fops_open() and IOMMU_TEST_CMD perform no capability checks; /dev/iommu is 0660 and MOCK_DOMAIN creates an IOPF-capable mock device without physical assignment, so an unprivileged local user with iommufd access (selftest/syzkaller kernels or VFIO/iommufd group membership) can trigger it without init-namespace root.

UI:NUser interaction, none

Exploitation requires no victim action; the attacker programmatically opens iommufd, creates a mock domain, attaches a PASID, and races TRIGGER_IOPF against detach through their own file descriptors and ioctls.

S:CScope, changed

The freed object is struct iommufd_attach_handle used by iommu_report_device_fault() to dispatch domain->iopf_handler and complete IOMMU page faults; pre-fix TRIGGER_IOPF also accepted any bound idev, so corrupting those handles can hijack IOMMU fault/DMA isolation across the device-assignment boundary.

C:HConfidentiality impact, high

Use-after-free of iommufd_attach_handle lets an attacker reclaim the slab and control the domain pointer later read as attach_handle->domain->iopf_handler, enabling arbitrary kernel reads through the IOPF handler and fault-queue path.

I:HIntegrity impact, high

The UAF is a function-pointer dereference of domain->iopf_handler plus later handle use in iommufd_fault_iopf_handler; heap spraying yields an arbitrary write and control-flow hijack in the IOMMU fault-completion path.

A:HAvailability impact, high

Dereferencing the freed attach handle in find_fault_handler()/iommu_report_device_fault() causes a kernel oops or panic; the UAF is reliably crashable even when not fully exploited for code execution.