A race condition in the Linux kernel’s traffic control API allows two concurrent filter‑add commands on the same queue discipline to both fail, leaving an empty classifier prototype object linked in the chain. The object is left unreclaimed, holding chain, block, and module references. Over time this can consume kernel resources and destabilize the networking stack, possibly leading to loss of packet filtering or service interruption (inferred).

All Linux kernel configurations that enable the Flower classifier (CONFIG_NET_CLS_FLOWER=y) and use libtc commands are affected. The problem exists in kernel versions prior to the commit that removes the residual empty prototype from the chain. Distributions shipping kernels before that fix, regardless of vendor, are vulnerable. Anything that runs the tc binary with CAP_NET_ADMIN privileges inside a network namespace can trigger the race.

The exploit requires local control with CAP_NET_ADMIN or root, and the attacker must orchestrate simultaneous filter‑add operations to reproduce the race. The EPSS score is < 1% and the vulnerability does not appear in the CISA KEV catalog. While the attack is limited to systems that use the Flower classifier, the impact could be high if an attacker is able to exhaust kernel resources or cause a denial of service (inferred). The CVSS score is 3.3, indicating a low‑severity risk but still potential for DoS (inferred).