CVE-2026-74739: net/sched: cls_u32: skip hash tables in u32_bind_class()
In the Linux kernel, the following vulnerability has been resolved:
net/sched: clsu32: skip hash tables in u32bindclass()
u32walk() enumerates both struct tcuhnode and struct tcuknode through the walker callback. u32bindclass() unconditionally casts the passed fh to tcuknode and accesses &n->res, so when fh is actually a tcuhnode, which has no tcfresult member, this results in a slab-out-of-bounds read of res->classid in tcclsbindclass().
The issue can be reproduced with the following commands:
tc qdisc add dev lo root handle 1: hfsc tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit
Fix this by skipping hash tables via the TCU32KEY(handle) check.
Affected Software
Event History
Frequently Asked Questions
What configuration sequence is known to trigger the issue?
The provided reproduction creates an HFSC root qdisc and class on the loopback device, adds a u32 filter with flowid 1:1, and then adds another HFSC class under the root. During this sequence, a hash-table entry can be handled as though it were a u32 key node.
What does the fix change?
The fix checks TC_U32_KEY(handle) in u32_bind_class() and skips hash tables. This prevents a tc_u_hnode from being cast to tc_u_knode and prevents the resulting out-of-bounds read of res->classid.
How can administrators assess whether their setup resembles the reported case?
Review traffic-control configuration for HFSC classes combined with u32 filters, particularly configurations where a u32 filter is added with a flowid and additional classes are subsequently created. The issue was reproduced on the loopback interface, but the provided data does not limit it to that interface.