CVE-2026-74520

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

Exploitation requires local ioctl/read/write on /dev/iommu or /dev/vfio and the iommufd fault-queue fd; the UAF is reached only through userspace-driven IOPF setup, fault delivery, and detach/HWPT-replace, not via any network packet or remote protocol handler.

AC:LAttack complexity, low

The attacker controls both sides of the race by concurrently triggering IOMMU page faults (device DMA to unmapped IOVAs) and detaching or replacing the HWPT via iommufd ioctls, then reading/responding on the fault fd; no victim timing or uncontrollable memory layout is required.

PR:LPrivileges required, low

Only a local process with access to an iommufd/VFIO context and an IOPF-capable assigned device (typical GPU/accelerator passthrough tenant) is needed; no host root/CAP_SYS_ADMIN is required once the device is bound to the caller's iommufd fd.

UI:NUser interaction, none

All steps—allocating the fault queue, attaching a fault-enabled HWPT, provoking PRI/IOPF events, detaching/replacing, and reading/writing the fault fd—are performed entirely by the attacking process without requiring any separate victim user action.

S:CScope, changed

The UAF corrupts iopf_group objects that hold attach_handle and fault_param pointers governing IOMMU page-fault responses and DMA translation; successful exploitation can bypass IOMMU DMA isolation or compromise the host from a VFIO device assignment security boundary.

C:HConfidentiality impact, high

Use-after-free of iopf_group lets an attacker reclaim the freed slab and control fields such as attach_handle and fault_param, enabling arbitrary kernel memory reads through subsequent fault-queue read/response paths and iopf_group_response dereferences.

I:HIntegrity impact, high

Controlled reuse of the freed iopf_group can corrupt list/xarray links and attach_handle pointers used by iopf_group_response and IOMMU fault completion, providing heap-spray-based arbitrary write and potential control-flow hijack for privilege escalation or DMA remapping.

A:HAvailability impact, high

Accessing a freed iopf_group during fault-fd read, write, auto-response on detach, or fault-object destruction causes kernel oops/panic; the bug is a confirmed UAF in a hot fault-handling path with reliably triggerable crash outcomes.