Live › vulnerability › CVE-2026-98610
Go to dashboardA crafted set of HFSC traffic-control filters makes the kernel's packet classifier loop endlessly between two classes while holding a lock, causing a soft lockup from a single packet. The sources describe a denial of service; they do not describe code execution.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with CONFIG_NET_SCH_HFSC and CONFIG_NET_CLS_U32 enabled, where a user can configure traffic control on an interface, including inside an unprivileged user and network namespace created with unshare. Hosts where HFSC is not built in or where only trusted administrators can set traffic-control rules are less exposed. The sources do not say which kernel versions are fixed.
No product ranges from the sources yet.
uname -r and compare against the fixed kernel releases listed in the NVD entrylsmod | grep sch_hfsc or grep CONFIG_NET_SCH_HFSC /boot/config-$(uname -r)sysctl kernel.unprivileged_userns_clone or sysctl user.max_user_namespaceslsmod | grep sch_hfsc and unload if not neededEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_hfsc: bound the classify inner-filter walk with a drift budget
hfsc_classify() applies the "filter may only point downwards" level check only when the filter result carries no bound class. A filter created with a flowid gets res.class set once at bind time, so the check never runs for it during classification. hfsc_adjust_levels() can later raise a class's level without revalidating existing bindings, leaving two binds that were each legal at bind time pointing at each other; the classify walk then bounces between two interior classes forever with the qdisc lock held and BH disabled — a soft lockup from a single packet. The stuck walk trips the watchdog:
watchdog: BUG: soft lockup - CPU#3 stuck for 13s! [ping:444] RIP: 0010:u32_classify+0x542/0x17f0 ... tcf_classify+0x66/0xa0 hfsc_enqueue+0x166/0xdf0
Bound the traversal with a budget of non-descending hops, the only way a configured walk can move without descending the class tree once levels drift after bind time. The budget is cumulative over the whole walk and is deliberately not reset on a descending hop: a chain that alternates a descent with a lateral hop would return the budget every lap and never trip. Descending hops never decrement it, so legitimately deep trees are unaffected and a terminating lateral chain still classifies normally. Drop the packet with a rate-limited warning once the budget is exhausted, mirroring the merged HTB fix.
This is a follow-up to commit 729c4896ab82 ("net/sched: sch_htb: limit htb_classify inner-class filter hops"), which bounded the same classify loop on the HTB side but left the HFSC walk unbounded.
Conditions to recreate the bug:
This page as .md · .json · in your agent: get_signal("CVE-2026-98610")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.