CVE-2026-98610
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's network traffic handling can freeze the system when certain network configurations are used.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Denial of service
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
hfsc_classify() performs an unbounded inner-filter walk that can enter an infinite lateral loop between two interior classes after hfsc_adjust_levels() raises a class level without revalidating bindings, holding the qdisc lock with BH disabled and triggering a soft lockup.
Why it matters to the business
Systems using the HFSC qdisc with u32 classifiers may experience CPU soft lockups or panics from a single packet, leading to temporary loss of network processing or system instability; the issue is reachable by unprivileged users via network namespaces.
How an attack unfolds
An attacker with CAP_NET_ADMIN creates two HFSC classes and u32 filters whose flowid bindings become cyclic after a later level change, then injects one packet that causes the classify walk to spin indefinitely under the qdisc lock.
How to fix it
Upgrade to a kernel containing the fix that bounds the classify walk with a non-descending hop budget; apply the patch that mirrors the earlier HTB change; rebuild and reboot with the updated kernel.
How to confirm the fix worked
Confirm the kernel contains the budget-bounded hfsc_classify implementation; attempt the documented recreation steps with softlockup_panic enabled and verify the walk terminates instead of looping; monitor for absence of the soft lockup message.
Typical attack path
- Obtain CAP_NET_ADMIN via unshare -Urn or equivalent
- Configure HFSC classes and u32 filters that are each legal at bind time but form a cycle after a subsequent level drift
- Send a single packet that triggers hfsc_enqueue and the unbounded classify walk
- Observe soft lockup or watchdog panic while qdisc lock remains held
How to detect it
Search kernel logs for soft lockup or watchdog messages referencing u32_classify or hfsc_enqueue; inspect audit logs for unshare or CAP_NET_ADMIN usage followed by network configuration changes; correlate with qdisc lock contention traces.
- watchdog: BUG: soft lockup - CPU.* stuck for .*s!
- u32_classify+0x542/0x17f0
- hfsc_enqueue+0x166/0xdf0
- tcf_classify+0x66/0xa0
What your security team should do
- Prioritize kernel upgrade on any system exposing HFSC qdisc with u32 filters
- Disable CONFIG_NET_SCH_HFSC or CONFIG_NET_CLS_U32 where the functionality is not required
- Enable softlockup detection and monitor kernel logs for related watchdog messages
- Restrict CAP_NET_ADMIN to trusted processes only
The record
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: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HFSC, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Build a cycle with two legal-at-bind-time flowid binds and a level drift: class X 1:1 (child of root) with leaf child 1:10; class Y 1:2 (sibling of X) with children 1:20 and 1:200; root u32 filter flowid 1:1; filter on X flowid 1:2 (legal when Y is a leaf); after Y's level rises to 2, filter on Y flowid 1:1 (legal then). Send one packet (ping on the device). Unfixed kernel: classify spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|