CVE-2026-68347: Linux Kernel Race Condition Vulnerability

CVE-2026-68347 Overview

CVE-2026-68347 affects the Linux kernel's AMD Input-Output Memory Management Unit (IOMMU) driver. The vulnerability stems from an IRQ-unsafe locking pattern in the guest domain (gdom) allocation path. Lockdep detects a HARDIRQ-safe to HARDIRQ-unsafe lock order between domain->lock and the XArray xa_lock used during nested domain allocation. The issue was resolved by switching gdom_info_load_or_alloc_locked() and the corresponding IOMMU_DESTROY free path to HARDIRQ-safe locking primitives. The flaw impacts kernel builds using the AMD IOMMU with the iommufd subsystem for nested hardware page table allocation.

Critical Impact
The inverted lock ordering can produce deadlocks on systems that acquire domain->lock from hard interrupt context, such as during NVMe IRQ completion and IOTLB flush operations.

Affected Products

Linux kernel builds with the AMD IOMMU driver enabled
Systems using the iommufd subsystem for nested Hardware Page Table (HWPT) allocation
Guest virtualization workloads (for example, QEMU/KVM) that trigger amd_iommu_alloc_domain_nested

Discovery Timeline

2026-08-10 - CVE-2026-68347 published to the National Vulnerability Database
2026-08-10 - Last updated in NVD database

Technical Details for CVE-2026-68347

Vulnerability Analysis

The defect lives in the AMD IOMMU driver path amd_iommu_alloc_domain_nested(), which is reachable through iommufd_hwpt_alloc() via the iommufd_fops_ioctl() entry point. During allocation, the driver acquires an XArray spinlock (xa->xa_lock) using _raw_spin_lock(), which is not IRQ-safe.

Elsewhere, amd_iommu_iotlb_sync() acquires domain->lock from hard interrupt context. The flush path then calls __domain_flush_pages(), which in turn acquires the same xa_lock. This creates a nested acquisition of xa_lock while domain->lock is held from IRQ context.

Lockdep flags the resulting order as a HARDIRQ-safe to HARDIRQ-unsafe lock dependency. If a hard interrupt fires on a CPU that already holds xa_lock through the non-IRQ-safe path, the interrupt handler can attempt to reacquire the same lock and deadlock the CPU.

Root Cause

The allocation site in gdom_info_load_or_alloc_locked() used _raw_spin_lock() rather than _raw_spin_lock_irqsave(). The corresponding free path invoked from IOMMU_DESTROY shared the same non-IRQ-safe pattern. Because amd_iommu_domain_flush_pages() must hold domain->lock while flushing, the two lock classes participate in inverted ordering across contexts. This is a kernel locking defect in the race condition and deadlock category [CWE-667].

Attack Vector

The reported trigger path involves an unprivileged or privileged local workload invoking iommufd IOCTLs (IOMMU_HWPT_ALLOC) concurrently with DMA activity that generates IOTLB flushes, such as NVMe I/O completion. Reproduction requires local access to the iommufd device and hardware paths that exercise amd_iommu_iotlb_sync() from IRQ context. No remote attack surface exists. The public disclosure describes the lockdep splat produced during QEMU virtualization workloads on affected kernels; no exploit code has been published and the vulnerability is not listed on the CISA Known Exploited Vulnerabilities catalog.

The vulnerability manifests through kernel locking primitives. See the upstream patches referenced below for the exact source-level change.

Detection Methods for CVE-2026-68347

Indicators of Compromise

Lockdep warnings in kernel logs matching HARDIRQ-safe -> HARDIRQ-unsafe lock order detected referencing &domain->lock and &xa->xa_lock
Stack traces including __domain_flush_pages, amd_iommu_iotlb_sync, and amd_iommu_alloc_domain_nested
Soft lockup or hung task reports on systems running iommufd with AMD IOMMU under DMA-heavy virtualization workloads

Detection Strategies

Inventory Linux hosts running AMD CPUs with CONFIG_AMD_IOMMU and CONFIG_IOMMUFD enabled, then compare kernel versions against upstream fixed commits 0db3a430d968 and e0c78cdf35af.
Enable CONFIG_PROVE_LOCKING in test environments to surface the lockdep splat before production exposure.
Correlate dmesg output through centralized log ingestion to identify recurring lockdep warnings tied to the AMD IOMMU subsystem.

Monitoring Recommendations

Ingest /var/log/kern.log and journalctl -k output into a centralized log platform and alert on WARNING: HARDIRQ-safe patterns.
Track kernel package versions across the fleet and flag hosts still running vulnerable builds after the vendor patch is available.
Monitor virtualization hosts for QEMU processes issuing repeated IOMMU_HWPT_ALLOC IOCTLs alongside I/O stalls.

How to Mitigate CVE-2026-68347

Immediate Actions Required

Apply distribution kernel updates that include upstream commits 0db3a430d968 and e0c78cdf35af on all AMD hosts running iommufd.
Restrict access to /dev/iommu to trusted service accounts and virtualization daemons only.
Reboot hosts after the patched kernel is installed to load the fixed IOMMU driver code path.

Patch Information

Upstream fixes are available in the kernel stable tree. See the Kernel Git Commit 0db3a430d968 and the Kernel Git Commit e0c78cdf35af. The fix converts gdom_info_load_or_alloc_locked() and the IOMMU_DESTROY free path to use IRQ-safe spinlock helpers so that xa_lock acquisitions match the HARDIRQ-safe class already used by domain->lock.

Workarounds

Disable the iommufd interface or restrict its IOCTLs where nested HWPT allocation is not required by the workload.
Avoid concurrent AMD IOMMU nested domain allocation and heavy DMA workloads on unpatched hosts until the kernel update is applied.
Where feasible, boot with amd_iommu=off on systems that do not require IOMMU translation, understanding the security trade-offs of disabling DMA remapping.

bash

# Verify running kernel and confirm the AMD IOMMU driver state
uname -r
dmesg | grep -iE 'AMD-Vi|iommu' | head -n 20

# Check for lockdep warnings related to this defect
journalctl -k | grep -E 'HARDIRQ-safe|amd_iommu_alloc_domain_nested'

# Restrict access to the iommufd device node
chmod 0600 /dev/iommu
chown root:root /dev/iommu