CVE-2026-74520: Linux kernel · iommu/iommufd: Fix IOPF group ownership UAF
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 8.8 High · fixed in 8563099bc4b03e1894a983a394225d69b05d9277 : patch Linux kernel soon.
Data as of 26 Oct 2026, 14:05 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 6% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers cannot reliably automate steps 1–4 of the kill chain
- Technical impact
- Total control over the software or total information disclosure
CISA SSVC assessment, 2026-10-16.
- Patch
- Available – fixed in 8563099bc4b03e1894a983a394225d69b05d9277, 738e6f32e61d80b554e37015ecb7bc620b88001c, 6da8f37419dd4c456f26fc203f04e000186f4b3d +1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 15 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade Linux kernel to 8563099bc4b03e1894a983a394225d69b05d9277, 738e6f32e61d80b554e37015ecb7bc620b88001c, 6da8f37419dd4c456f26fc203f04e000186f4b3d or 4e74a369236424114b94cf6a9f5ff9e848b430b4.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
Description
In the Linux kernel, the following vulnerability has been resolved: iommu/iommufd: Fix IOPF group ownership UAF iopf_group_alloc() links each last-page IOPF group into the generic IOPF pending list before invoking the domain fault handler. iommufd_fault_iopf_handler() also queued an accepted group in the IOMMUFD deliver list without removing it from the generic pending list. When detach or HWPT replacement drops the device's IOPF reference count to zero, an IOMMU driver may call iopf_queue_remove_device(). That function responds to and frees groups through the generic pending list without removing the same groups from IOMMUFD's deliver list or response xarray. A later read, response, or cleanup can then access the freed group and cause a UAF. Fix this by dequeuing an accepted group from the generic pending list before IOMMUFD queues it for userspace response. Make iopf_group_response() send a response regardless of pending-list membership, so the dequeued group can still be completed by IOMMUFD.
References
- git.kernel.org/stable/c/8563099bc4b03e1894a983a394225d69b05d9277 (opens in a new tab)
- git.kernel.org/stable/c/6da8f37419dd4c456f26fc203f04e000186f4b3d (opens in a new tab)
- git.kernel.org/stable/c/4e74a369236424114b94cf6a9f5ff9e848b430b4 (opens in a new tab)
- git.kernel.org/stable/c/738e6f32e61d80b554e37015ecb7bc620b88001c (opens in a new tab)