The issue resides in the Linux kernel's hmm_range_fault path, where a failed folio_trylock leads to an active spin until the device‑private folio lock is released. When the lock holder is itself awaiting a work item scheduled on the same CPU—such as the lru_add_drain_all routine—the spinning thread can never make progress. This produces a livelock or starvation scenario that never resolves, effectively blocking migration of device memory to RAM and potentially halting application or system responsiveness.

All Linux kernel versions prior to the commit that introduced the waiting logic are affected. The vulnerability was discovered in kernel commit a69d1ab, and the patch applies to all downstream kernels from that point onward. No vendor‑specific version numbers are listed, so the remedy applies to recent LTS and mainline kernels that have not yet incorporated the fix.

The EPSS score is not available, and the CVE has not been listed in CISA KEV. The CVSS score is 5.5, indicating medium severity. Based on the description, exploitation requires the specific condition where a process holding a device‑private folio lock also needs a work item to run on the same CPU; this is an uncommon scenario, as demonstrated only by the igt test harness. Therefore the risk of real‑world exploitation is considered low, but the impact, if triggered, would be disruptive. The likely attack vector is internal and requires a user or system process that can induce specific memory migration paths.