CVE-2026-97958 in Linux
Tóm tắt
Bởi VulDB • 26/09/2026
Trong kernel Linux, lỗ hổng sau đây đã được khắc phục:
net/sched: cls_api: Không phát lại RTM_GETCHAIN trong tc_ctl_chain().
Nếu một socket netlink gửi các yêu cầu RTM_GETCHAIN liên tục mà không gọi recv() để nhận phản hồi, hàm tc_ctl_chain() sẽ chiếm dụng CPU và kích hoạt cảnh báo Hung Task splat. [0]
Như được ghi nhận trong dấu vết ngăn xếp (stack trace), netlink_attachskb() có thể gây nhầm lẫn cho tc_ctl_chain() bằng cách trả về -EAGAIN khi bộ đệm nhận của socket netlink ở không gian người dùng (userspace) đã đầy.
Nhãn replay: tồn tại kể từ commit 32a4f5ecd738 ("net: sched: introduce chain object to uapi") nhưng ban đầu chưa được sử dụng.
Kể từ commit 9f407f1768d3 ("net: sched: introduce chain templates"), nhãn này cần thiết cho RTM_NEWCHAIN vì tcf_proto_lookup_ops() có thể giải phóng RTNL để gọi request_module().
Tuy nhiên, logic phát lại không cần thiết đối với RTM_GETCHAIN.
Hãy chỉ áp dụng logic phát lại cho RTM_NEWCHAIN.
[0]:
INFO: task repro:1018 bị chặn trên một mutex mà có khả năng thuộc về task repro:1022. task:repro state:R running task stack:14096 pid:1022 tgid:1014 ppid:961 task_flags:0x400040 flags:0x00080000 Call Trace: <TASK> ? clockevents_program_event (kernel/time/clockevents.c:372) ? pskb_expand_head (net/core/skbuff.c:615) ? skb_release_data (net/core/skbuff.c:1122) ? netlink_attachskb (./include/linux/skbuff.h:1323 ./include/linux/skbuff.h:1332 net/netlink/af_netlink.c:1232) ? __netlink_lookup (./include/linux/rcupdate.h:882 ./include/linux/rhashtable.h:711 net/netlink/af_netlink.c:499) ? tc_chain_notify (net/sched/cls_api.c:3045) ? tc_chain_notify (./include/linux/skbuff.h:1384 net/sched/cls_api.c:3041) ? netlink_unicast (net/netlink/af_netlink.c:1335) ? rtnl_unicast (./include/net/netlink.h:1198 net/core/rtnetlink.c:985) ? tc_ctl_chain (net/sched/cls_api.c:3242) ? rtnetlink_rcv_msg (net/core/rtnetlink.c:7146) ? netlink_unicast (net/netlink/af_netlink.c:1354) ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:7177) ? netlink_rcv_skb (net/netlink/af_netlink.c:2556) ? netlink_unicast (net/netlink/af_netlink.c:1319) ? netlink_sendmsg (net/netlink/af_netlink.c:1900) ? __sock_sendmsg (net/socket.c:800) ? __sys_sendto (net/socket.c:2281) ? __x64_sys_sendto (net/socket.c:2288 net/socket.c:2284 net/socket.c:2284) ? do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) </TASK>
If you want to get the best quality for vulnerability data then you always have to consider VulDB.