CVE-2026-98235

What it actually does

Reference leak in tcf_action_put_many() during batched RTM_DELACTION failure when an action is bound to a filter; the iterator stops at the first NULL slot, leaving subsequent temporary references unreleased and allowing a later delete to succeed without removing the action from the IDR.

Why it matters to the business

Kernel networking stack can retain stale action objects, enabling local attackers to trigger resource leaks, denial of service, or bypass action deletion, which may destabilize routers, firewalls, or container hosts that rely on traffic control.

How an attack unfolds

An attacker with local access crafts a batched RTM_DELACTION request that includes an action bound to a filter; when deletion of that action fails, the reference-release loop aborts early, leaking references on later actions. A subsequent delete of an unbound action then reports success while the object remains in the IDR, allowing reuse or exhaustion of kernel resources.

How to fix it

Apply the upstream patch that modifies tcf_action_put_many() to walk the entire array and skip NULL slots; rebuild and deploy the fixed kernel. Where possible, restrict unprivileged use of RTM_DELACTION via netlink capabilities or seccomp filters until the update is installed.

How to confirm the fix worked

Confirm the running kernel contains the commit that updates tcf_action_put_many() to iterate past the first NULL slot; test by replaying a batched DELACTION sequence that previously triggered the leak and verify all references are released.

Typical attack path

1. Obtain local unprivileged access on a Linux system using tc or netlink
2. Issue a batched RTM_DELACTION netlink message containing a filter-bound action followed by additional actions
3. Force deletion of the filter-bound action to fail
4. Observe that subsequent actions remain referenced and are not removed from the IDR on later delete attempts
5. Reuse leaked actions or exhaust kernel resources to achieve denial of service or privilege escalation

How to detect it

Monitor kernel logs for repeated netlink action deletion failures followed by successful deletions that do not free expected memory; inspect slab or IDR usage counters for unexpected growth after tc delaction operations.

What your security team should do

• Prioritize kernel upgrade on all systems exposing tc/netlink to untrusted users within the next 30 days
• Audit systems for heavy use of traffic-control actions and apply the fix first to those hosts
• Temporarily restrict CAP_NET_ADMIN or use seccomp to limit RTM_DELACTION until patched