CVE-2026-97958: net/sched: cls_api: Don't replay RTM_GETCHAIN in tc_ctl_chain().
In the Linux kernel, the following vulnerability has been resolved:
net/sched: clsapi: Don't replay RTMGETCHAIN in tcctlchain().
If a netlink socket sends RTMGETCHAIN requests repeatedly without recv()ing the responses, tcctlchain() hogs CPU and triggers Hung Task splat. [0]
As caught in the stack trace, netlinkattachskb() could confuse tcctlchain() by returning -EAGAIN when the userspace netlink socket's receive buffer is full.
The replay: label exists since commit 32a4f5ecd738 ("net: sched: introduce chain object to uapi") but was not used initially.
Since commit 9f407f1768d3 ("net: sched: introduce chain templates"), the label is needed for RTMNEWCHAIN because tcfprotolookupops() may release RTNL to call requestmodule().
However, the replay logic is unnecessary for RTMGETCHAIN.
Let's apply the replay logic only for RTMNEWCHAIN.
[0]: INFO: task repro:1018 is blocked on a mutex likely owned by task repro:1022. task:repro state:R running task stack:14096 pid:1022 tgid:1014 ppid:961 taskflags:0x400040 flags:0x00080000 Call Trace: <TASK> ? clockeventsprogramevent (kernel/time/clockevents.c:372) ? pskbexpandhead (net/core/skbuff.c:615) ? skbreleasedata (net/core/skbuff.c:1122) ? netlinkattachskb (./include/linux/skbuff.h:1323 ./include/linux/skbuff.h:1332 net/netlink/afnetlink.c:1232) ? netlinklookup (./include/linux/rcupdate.h:882 ./include/linux/rhashtable.h:711 net/netlink/afnetlink.c:499) ? tcchainnotify (net/sched/clsapi.c:3045) ? tcchainnotify (./include/linux/skbuff.h:1384 net/sched/clsapi.c:3041) ? netlinkunicast (net/netlink/afnetlink.c:1335) ? rtnlunicast (./include/net/netlink.h:1198 net/core/rtnetlink.c:985) ? tcctlchain (net/sched/clsapi.c:3242) ? rtnetlinkrcvmsg (net/core/rtnetlink.c:7146) ? netlinkunicast (net/netlink/afnetlink.c:1354) ? pfxrtnetlinkrcvmsg (net/core/rtnetlink.c:7177) ? netlinkrcvskb (net/netlink/afnetlink.c:2556) ? netlinkunicast (net/netlink/afnetlink.c:1319) ? netlinksendmsg (net/netlink/afnetlink.c:1900) ? socksendmsg (net/socket.c:800) ? syssendto (net/socket.c:2281) ? x64syssendto (net/socket.c:2288 net/socket.c:2284 net/socket.c:2284) ? dosyscall64 (arch/x86/entry/syscall64.c:61 arch/x86/entry/syscall64.c:84) ? entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121) </TASK>
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Modify tc_ctl_chain() in net/sched/cls_api.c so replay logic is applied only to RTM_NEWCHAIN requests and not to RTM_GETCHAIN requests; return -EAGAIN when the userspace netlink socket's receive buffer is full.
Event History
Frequently Asked Questions
What conditions are required to trigger the CPU hog?
A userspace process must repeatedly send RTM_GETCHAIN requests through a netlink socket without receiving the responses. Once the socket receive buffer is full, netlink_attachskb() can return -EAGAIN and cause tc_ctl_chain() to replay the request.
Who can trigger this issue?
The triggering activity is performed through a userspace netlink socket using RTM_GETCHAIN requests. The provided information does not identify any remote network trigger or additional prerequisite beyond the ability to send those requests.
How might an affected system behave?
The kernel can spend excessive CPU in tc_ctl_chain() and emit a Hung Task warning. The reported condition includes a task blocked on a mutex while another task remains running.