Linux Kernel EUVD-2026-27816

Exploitation requires AMD processor hardware with IOMMU feature enabled in BIOS, Linux kernel compiled with AMD IOMMU driver support (CONFIG_AMD_IOMMU=y), and non-default kernel boot parameter iommu.strict=1 explicitly configured. The strict mode setting is not enabled by default in most distributions-administrators must intentionally enable it for security-hardened or real-time environments. Additionally, sustained high DMA throughput is necessary to trigger spinlock contention, typically requiring multi-core systems under heavy I/O load (virtualization, high-speed networking, NVMe storage). Intel systems or AMD systems without IOMMU hardware are not vulnerable. Systems running default kernel parameters (iommu.strict=0 or unset) are not affected regardless of hardware.

Real-world risk assessment reveals moderate practical impact despite CVSS 7.5 score. The CVSS vector (AV:N/AC:L/PR:N/UI:N) appears inconsistent with the vulnerability nature-this is a local kernel denial-of-service condition requiring kernel module loading and AMD IOMMU hardware presence, not a network-accessible vulnerability. Attack vector should realistically be AV:L. The 0.02% EPSS score (5th percentile) correctly reflects low exploitation likelihood, as triggering requires specific hardware (AMD processors with IOMMU), non-default kernel configuration (iommu.strict=1), and sustained high DMA activity. No CISA KEV listing indicates no observed exploitation. Impact is limited to availability (soft lockups, system hangs) without confidentiality or integrity compromise. Priority should be moderate for production systems using AMD IOMMU in strict mode, particularly virtualization hosts or real-time systems where kernel responsiveness is critical. For systems not using strict mode or lacking AMD IOMMU hardware, risk is negligible. The CVSS network vector discrepancy suggests potential scoring error-verify with vendor advisory before prioritizing as externally exploitable.

An attacker with local access to a Linux system using AMD IOMMU in strict mode triggers high-volume DMA operations through legitimate kernel interfaces (network I/O, disk operations, GPU activity). The sustained IOMMU command submission rate causes the vulnerable completion wait path to enter prolonged busy-wait loops under spinlock, starving CPU scheduling and triggering soft lockup detection. System responsiveness degrades severely, causing service disruption or complete system hang requiring physical reboot. No public POC exists but exploitation is straightforward on affected configurations using standard I/O stress tools.