CVE-2026-98610

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: