A fault in the Linux kernel networking scheduler caused the loop‑detection logic for mirred (mirror) redirects to fail when a packet is redirected from ingress or egress to another device and back. The bookkeeping array that records in‑flight mirred operations is cleared unexpectedly, so a looping configuration is not detected. This flaw results in packets continuing to be processed indefinitely, potentially exhausting kernel resources or causing kernel stalls. The vulnerability is purely functional and does not provide code execution or privilege escalation. It is associated with CWE‑835 (Resource Exhaustion).

All Linux kernel builds older than the commit that introduced the mirred loop‑tracking fix. The issue resides in the core networking scheduler and affects any distribution that has not incorporated the upstream patch. No specific versions are listed in the CVE payload, so any kernel version before the fix remains vulnerable.

The EPSS score is reported as less than 1%, indicating a very low likelihood of exploitation, and the vulnerability is not listed in CISA’s KEV database. An attacker would need to craft network traffic that activates a mirred mirroring loop across two devices, which requires precise configuration of mirred filters on the involved interfaces. This limits the practical attack surface, but if the loop were triggered it could lead to denial of service by exhausting kernel resources or pausing the networking stack.