CVE-2026-90053 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
net/sched: sch_htb: limit htb_classify inner-class filter hops
htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet.
Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at the point the inner filter chain is picked up, after the TC_ACT_* switch has consumed the classifier verdict, so a terminal TC_ACT_QUEUED/STOLEN/TRAP on the last permitted chain still sets *qerr to __NET_XMIT_STOLEN and the packet is not charged as a drop by this qdisc or its parent.
The bound is TC_HTB_MAXDEPTH, taken from HTB's own parameters rather than from the qdisc hierarchy depth limit. Class levels run from 0 to TC_HTB_MAXDEPTH - 1, so a traversal that strictly descends in level can take at most TC_HTB_MAXDEPTH hops. That descent is what a sane configuration does, but it is assumed here rather than enforced: htb_find() resolves a classid against every class in the qdisc, so a filter may equally select a sibling or an ancestor. The normal root -> inner -> leaf path takes a single hop, so the bound does not affect legitimate classification.
htb_classify() can now return NULL irrespective of CONFIG_NET_CLS_ACT, whereas previously every NULL return sat inside that ifdef. The NULL handler in htb_enqueue() therefore cannot stay conditional either, so drop the ifdef around it. This matches hfsc_enqueue(), which has always handled a NULL class unconditionally. Without it, a kernel built without actions would dereference a NULL class instead of dropping.
Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_SCH_HTB, CONFIG_NET_CLS_U32, CONFIG_LOCKUP_DETECTOR. - Create an HTB qdisc on a device (e.g. lo), add an inner class 1:1 with a leaf child 1:10, install a root u32 filter selecting 1:1, and an inner-class u32 filter on 1:1 also selecting 1:1. - Send one packet (ping). On the unfixed kernel the classify loop spins with the qdisc lock held; with softlockup_panic=1 it panics. - Reachable from unprivileged user via unshare -Urn (CAP_NET_ADMIN).
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel vulnerability identified in the net/sched sch_htb subsystem represents a critical denial of service condition arising from an infinite loop within the packet classification logic. Specifically, the htb_classify function is responsible for traversing filter lists to determine how packets should be handled by Hierarchical Token Bucket (HTB) queuing disciplines. The core technical flaw lies in the lack of bounds checking when following filter-selected inner classes. When a classifier selects an inner class, the code switches to that class's filter list without verifying whether this traversal has already occurred or exceeded a safe limit. This oversight allows for circular references where a filter on an inner class points back to itself or to another inner class that eventually loops back, creating an infinite cycle in the packet classification path. Because this loop executes while holding the qdisc lock and with bottom-half processing disabled, it prevents other kernel tasks from running, leading directly to soft lockups or system panics triggered by a single crafted packet.
The operational impact of this vulnerability is severe, as it allows for remote or local denial of service attacks that can destabilize network functionality on affected systems. An attacker who possesses the CAP_NET_ADMIN capability, which can be obtained through unprivileged user namespaces via the unshare command with specific flags, can configure malicious HTB qdiscs and filters to trigger this loop. The vulnerability is particularly dangerous because it does not require elevated privileges beyond those typically granted for network configuration tasks within a container or namespace environment. Once triggered, the infinite loop consumes CPU resources indefinitely while holding critical kernel locks, effectively freezing network processing on the affected interface and potentially causing broader system instability depending on the softlockup detector settings configured in the kernel.
The resolution involves implementing a strict hop counter to bound the traversal depth during classification. The fix introduces TC_HTB_MAXDEPTH as the maximum allowed number of hops for inner filter chain traversals, aligning with existing HTB parameters rather than general qdisc hierarchy limits. This approach assumes that sane configurations involve strictly descending class levels, which naturally limit traversal depth. By incrementing a counter when entering an inner filter chain and checking it against this bound, the kernel can detect circular references early in the process. If the hop count exceeds TC_HTB_MAXDEPTH, the packet is dropped immediately rather than processed further. This mechanism includes rate-limited warnings to alert administrators of potential misconfigurations or attacks without flooding logs with repetitive error messages for every affected packet.
In addition to preventing infinite loops, the patch addresses a secondary issue related to NULL pointer dereferences in environments where network action classifiers are disabled via CONFIG_NET_CLS_ACT. Previously, the handling of NULL class returns was conditional on this configuration option, leading to potential crashes when built without actions support. The fix ensures that htb_classify can return NULL unconditionally and updates htb_enqueue to handle these cases consistently with other queuing disciplines like hfsc_enqueue. This change prevents kernel panics caused by dereferencing a NULL class pointer in minimal configurations, thereby improving the robustness of the networking stack across various build options.
From a security classification perspective, this vulnerability aligns with CWE-835, which describes loops that do not terminate correctly due to missing bounds checks or counter updates. It also relates to CWE-400 regarding resource exhaustion through uncontrolled consumption of resources such as CPU time and memory locks. In the context of the MITRE ATT&CK framework, this vulnerability facilitates Denial of Service (T1499) by allowing an attacker to disrupt network availability on a targeted system or container environment. The exploitation vector is classified under Local Privilege Escalation if CAP_NET_ADMIN can be obtained through namespace manipulation, falling under T1068 Exploitation for Privilege Escalation in conjunction with the denial of service impact.
Mitigation strategies primarily involve applying the kernel patch that introduces the hop counter and NULL handling improvements. System administrators should ensure their Linux kernels are updated to versions containing this fix. For environments where immediate patching is not possible, restricting CAP_NET_ADMIN capabilities within user namespaces can reduce the attack surface by preventing unprivileged users from creating complex HTB filter chains capable of triggering the loop. Additionally, monitoring for soft lockup warnings in kernel logs can help identify potential exploitation attempts or misconfigurations that lead to similar infinite loops before they cause full system panics. Regular auditing of network configuration scripts and container security policies is recommended to prevent the deployment of circular filter references.