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
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38~24.04.4 - Upgrade
Upgrade
ubuntu/linux-nvidia-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1024.25~24.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-38.38 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1008.9 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-nvidia-bosto a version that resolves this vulnerability.Fixed in 7.0.0-2022.23 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Compensating control
In the Linux kernel AMD IOMMU code, use HARDIRQ-safe allocation in gdom_info_load_or_alloc_locked() and HARDIRQ-safe locking in the IOMMU_DESTROY->free path.
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.