CVE-2026-97959

What the bug is

route4_change can move an existing filter to a different top-level bucket: route4_set_parms recomputes the handle from TCA_ROUTE4_TO/ FROM/IIF, and the handle-mismatch check is gated on the 'new' flag, so for an existing filter the new handle may differ from the old one and land in a different bucket. When this happens, the filter is unlinked from the old bucket, but the bucket itself is never freed once it goes empty. The stale empty bucket remains in head->table[], causing route4_delete to report *last=false even after the last live filter is gone. That pins the empty tcf_proto and causes a leak. Fix this by refcounting the filters linked to a bucket and freeing the bucket when the count drops to zero. The existing scan in route4_delete goes away with it. The count is updated at all sites that link or unlink a filter during add, change and delete, and the bucket is dropped from head->table[] as soon as it reaches zero. Conditions to recreate the bug: CONFIG_NET_CLS_ROUTE4=y, CONFIG_NET_SCH_INGRESS=y, CONFIG_NET_CLS_ACT=y. tc qdisc replace dev lo clsact tc filter add dev lo ingress protocol ip pref 100 route from 1 to 1 tc filter change dev lo ingress protocol ip pref 100 handle 0x10001 \ route from 1 to 2 tc filter del dev lo ingress protocol ip pref 100 handle 0x10002 \ route from 1 to 2 tc filter show dev lo ingress | grep -c 'pref 100 route chain 0 '

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

net/sched/cls_route.c

What this is

TC subsystemMAINTAINERS section matched on net/sched/ · netdev@vger.kernel.org · Maintained

Kernel module

cls_route

Check it on the machine

grep -w CONFIG_NET_CLS_ROUTE4 /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

lsmod | grep -w cls_route

Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.

Show whether Debian builds this, per release

Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.

• bookworm, trixie, forky, sid, bookworm · linux-6.12m

m

a loadable module on every flavour - check lsmod, can be blacklisted

Build switch

CONFIG_NET_CLS_ROUTE4

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Signals

Published

2026-09-25 (24 days ago)source

CVSS

no vector published, unrated

Attack vector

not published

EPSS

0.18%, higher than 6.7% of all CVEssource

CISA KEV

not listedthe KEV catalogue

Debian urgency

not yet assignedsource

Subsystem

net/sched

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
4.1	5.10.271	9e7741b41a25
4.1	5.15.222	48d38bf8c22a
4.1	6.1.189	cc99d26b1243
4.1	6.6.158	41e94079200a
4.1	6.12.111	2e2f130951d3
4.1	6.18.53	f8495d67434e
4.1	7.2.7	81dd117c0442
4.1	7.3	1853f30cf5c8

Debian advisories