An internal deadlock in the Linux kernel’s iptfs module was discovered. The iptfs_destroy_state() routine calls hrtimer_cancel while holding a spinlock that the timer callback also acquires, and because the timers run in softirq context on SMP systems, this pattern induces an ABBA deadlock. The resulting system stall can prevent the kernel networking stack from functioning normally, effectively denying service to all processes that depend on it. The deadlock originates from an internal kernel race condition; it would require triggering the state destruction while a timer callback is executing, which an analyst infers could involve local or privileged access to the network is < 1% and the CVE is not listed in CISA’s KEV catalog, indicating limited observed exploitation. Without a quantified CVSS score, the severity is inferred from the potential for a system‑wide hang on SMP hardware. The breakup of lock ordering suggests a moderate to high risk of denial of service rather than remote code execution. (All inferences are marked as such.)

The flaw applies to any Linux kernel version that includes the iptfs module without the patch. No specific affected version range is provided in the data, so all kernels that contain the unpatched iptfs implementation—particularly those running on multi‑core systems—could be vulnerable. (This inference is based on the lack of specific version details.)

The deadlock originates from an internal kernel race condition; it would require triggering the state destruction while a timer callback is executing. An analyst infers that such a scenario could involve local or privileged access to the network stack. Because the exploitation context is internal, the risk largely pertains to denial of service rather than remote code execution. The EPSS score, indicating a very low probability of exploitation, combined with the absence from CISA’s KEV catalog, suggests that while the vulnerability can lead to a system‑wide hang on SMP hardware, real‑world exploitation likelihood is limited. The CVSS score is unavailable, so the severity assessment remains speculative, with a focus on the potential for a service disruption to all network‑dependent processes.