The fault in iommu/amd causes the kernel to hold a spinlock while busy‑waiting for a semaphore, keeping interrupts disabled and the lock held for an extended period. When iommu.strict=1 is enabled, this can lead to soft lock‑ups under high load or repeated wait conditions, making the system unresponsive. The weakness is a concurrency mis‑management flaw that requires no direct code execution or privileged access to manifest.

The issue resides in the Linux kernel; it affects any distribution that ships with the legacy iommu implementation that has not applied the patch referenced in the commit log. No specific version range is listed in the CVE metadata, so any kernel build containing the unpatched iommu code is potentially vulnerable.

The vulnerability has no publicly disclosed CVSS score; however the EPSS score is not available, and the flaw is not listed in the CISA KEV catalog. The likely attack vector involves generating or processing IOMMU requests that trigger the waiting path while iommu.strict=1 is set, which could be achieved by a local process or attacker with kernel‑level IOMMU manipulation capabilities. While the bug does not enable arbitrary code execution, it offers a straightforward denial‑of‑service path that can be exploited in environments with stressed hardware or repeated device reassignment.