CVE-2026-68347 in Linux
Summary
by MITRE • 08/10/2026
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->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0
[ 259.454485]
and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60
[ 259.470408] which would create a new lock dependency:
[ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#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] lock_acquire+0xb6/0x2e0
[ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60
[ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50
[ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0
[ 259.523534] __iommu_dma_unmap+0xc2/0x140
[ 259.528100] iommu_dma_unmap_phys+0x55/0xc0
[ 259.532863] dma_unmap_phys+0x274/0x2e0
[ 259.537238] dma_unmap_page_attrs+0x17/0x30
[ 259.542000] nvme_unmap_data+0x13e/0x280
[ 259.546473] nvme_pci_complete_batch+0x45/0x70
[ 259.551524] nvme_irq+0x83/0x90
[ 259.555123] __handle_irq_event_percpu+0x92/0x360
[ 259.560466] handle_irq_event+0x39/0x80
[ 259.564841] handle_edge_irq+0xb2/0x1a0
[ 259.569214] __common_interrupt+0x4e/0x130
[ 259.573882] common_interrupt+0x88/0xa0
[ 259.578256] asm_common_interrupt+0x27/0x40
[ 259.583019] cpuidle_enter_state+0x119/0x5d0
[ 259.587877] cpuidle_enter+0x2e/0x50
[ 259.591962] do_idle+0x153/0x2c0
[ 259.595657] cpu_startup_entry+0x29/0x30
[ 259.600128] start_secondary+0x118/0x150
[ 259.604601] common_startup_64+0x13e/0x141
[ 259.609266]
to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3}
[ 259.615386]
... which became HARDIRQ-irq-unsafe at: [ 259.627039] ...
[ 259.627039] lock_acquire+0xb6/0x2e0
[ 259.633071] _raw_spin_lock+0x2f/0x50
[ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0
[ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd]
[ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd]
[ 259.654547] __x64_sys_ioctl+0x9d/0xf0
...
Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability resides within the Linux kernel's input-output memory management unit implementation, specifically affecting AMD IOMMU drivers. The issue manifests as an improper lock ordering that violates kernel hardirq safety requirements, creating potential deadlock conditions and system instability. The problem occurs during IOMMU domain allocation operations where the kernel's lock dependency checker detects a dangerous locking sequence that could lead to system hangs or crashes.
The technical flaw stems from inconsistent locking behavior in the AMD IOMMU driver's gdom allocation mechanism. When processing IOMMU domain flush operations, the function amd_iommu_domain_flush_pages() acquires domain->lock while operating in an interrupt context, making this lock HARDIRQ-irq-safe. However, subsequent allocation operations attempt to acquire xa->xa_lock#25 from a context where this lock is not marked as hardirq-safe, creating a dependency chain that violates kernel locking semantics. This violates the fundamental principle of maintaining consistent lock ordering across different interrupt contexts, specifically CWE-691.
The operational impact of this vulnerability can be severe in virtualized environments or systems handling high-frequency IOMMU operations, particularly those involving GPU drivers like NVIDIA's nvme_unmap_data function that trigger the problematic code path. When the system encounters this lock ordering violation during DMA unmap operations, it may result in kernel oops, system hangs, or complete system crashes. The vulnerability affects systems using AMD IOMMU hardware with IOMMUFD (IOMMU Driver Framework) and can be exploited by malicious actors to cause denial of service conditions.
The fix addresses this issue by ensuring all allocation paths in gdom_info_load_or_alloc_locked() utilize hardirq-safe allocation mechanisms, specifically switching from regular to HARDIRQ-safe locking approaches. This change ensures that both the allocation and destruction paths maintain consistent locking semantics across interrupt contexts, preventing the lock dependency violations reported by Lockdep. The solution aligns with ATT&CK technique T1490 (Inhibit System Recovery) by preventing potential system instability and maintaining kernel operational integrity during IOMMU operations.
The mitigation strategy involves updating to a patched kernel version that implements the hardirq-safe locking mechanism for all IOMMU domain allocation and deallocation operations. Administrators should prioritize applying this patch in production environments, particularly those utilizing AMD IOMMU hardware with virtualization workloads or GPU-intensive applications. The fix specifically addresses the core issue of inconsistent lock acquisition ordering between domain->lock (which becomes hardirq-safe) and xa->xa_lock#25 (which remains hardirq-unsafe), resolving the fundamental locking inconsistency that could lead to system instability during concurrent IOMMU operations.