CVE-2026-68347: iommu/amd: Fix IRQ unsafe locking in gdom allocation
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix IRQ unsafe locking in gdom allocation
Lockdep complains:
[ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xalock#25){+.+.}-{3:3}, at: domainflushpages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amdiommuiotlbsync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xalock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lockacquire+0xb6/0x2e0 [ 259.507790] rawspinlockirqsave+0x3e/0x60 [ 259.512748] amdiommuflushiotlball+0x20/0x50 [ 259.517996] iommudmafreeiova.isra.0+0x1b8/0x1e0 [ 259.523534] iommudmaunmap+0xc2/0x140 [ 259.528100] iommudmaunmapphys+0x55/0xc0 [ 259.532863] dmaunmapphys+0x274/0x2e0 [ 259.537238] dmaunmappageattrs+0x17/0x30 [ 259.542000] nvmeunmapdata+0x13e/0x280 [ 259.546473] nvmepcicompletebatch+0x45/0x70 [ 259.551524] nvmeirq+0x83/0x90 [ 259.555123] handleirqeventpercpu+0x92/0x360 [ 259.560466] handleirqevent+0x39/0x80 [ 259.564841] handleedgeirq+0xb2/0x1a0 [ 259.569214] commoninterrupt+0x4e/0x130 [ 259.573882] commoninterrupt+0x88/0xa0 [ 259.578256] asmcommoninterrupt+0x27/0x40 [ 259.583019] cpuidleenterstate+0x119/0x5d0 [ 259.587877] cpuidleenter+0x2e/0x50 [ 259.591962] doidle+0x153/0x2c0 [ 259.595657] cpustartupentry+0x29/0x30 [ 259.600128] startsecondary+0x118/0x150 [ 259.604601] commonstartup64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xalock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lockacquire+0xb6/0x2e0 [ 259.633071] rawspinlock+0x2f/0x50 [ 259.637250] amdiommuallocdomainnested+0x140/0x3c0 [ 259.643078] iommufdhwptalloc+0x272/0x800 [iommufd] [ 259.648813] iommufdfopsioctl+0x14e/0x200 [iommufd] [ 259.654547] x64sysioctl+0x9d/0xf0 ...
Since amdiommudomainflushpages() necessarily holds domain->lock to do the flush, switch the allocation side in gdominfoloadoralloclocked() to HARDIRQ-safe allocation. The IOMMUDESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Linux kernelto a version that resolves this vulnerability.Patch iommu/amd: Fix IRQ unsafe locking in gdom allocation - Configuration
In gdom_info_load_or_alloc_locked(), switch the allocation-side locking to HARDIRQ-safe to match the HARDIRQ-safe requirements and avoid the HARDIRQ-safe -> HARDIRQ-unsafe lock order detected in __domain_flush_pages()/amd_iommu_iotlb_sync()
amd_iommu gdom_info_load_or_alloc_locked() IRQ-safe locking for gdom allocation path = HARDIRQ-safe
Event History
Frequently Asked Questions
What is the severity of CVE-2026-68347?
The severity of CVE-2026-68347 is rated at 34.
How do I fix CVE-2026-68347?
To fix CVE-2026-68347, update your Linux kernel to the latest version where the vulnerability has been patched.
What are the potential impacts of CVE-2026-68347?
CVE-2026-68347 may lead to improper locking mechanisms in the iommu/amd component, causing instability in IRQ handling.
Is CVE-2026-68347 exploitable remotely?
CVE-2026-68347 does not appear to be remotely exploitable as it relates to kernel-level locking in the Linux system.
When was CVE-2026-68347 published?
CVE-2026-68347 was published on August 10, 2026.