CVE-2026-97958 in Linux
요약
\~에 의해 VulDB • 2026. 09. 25.
리눅스 커널에서 다음 취약점이 해결되었습니다.
net/sched: cls_api: tc_ctl_chain()에서 RTM_GETCHAIN을 재전송하지 않음
네트워크 링크 소켓이 응답을 recv()하지 않고 반복적으로 RTM_GETCHAIN 요청을 보내면, tc_ctl_chain()이 CPU를 독점하고 Hung Task splat(블로킹된 태스크 경고)를 유발합니다. [0]
스택 트레이스에서 확인된 바와 같이, 사용자 공간의 네트워크 링크 소켓 수신 버퍼가 가득 차 있을 때 netlink_attachskb()는 -EAGAIN을 반환하여 tc_ctl_chain()에 혼란을 줄 수 있습니다.
replay: 레이블은 commit 32a4f5ecd738("net: sched: introduce chain object to uapi")부터 존재했지만 초기에는 사용되지 않았습니다.
commit 9f407f1768d3("net: sched: introduce chain templates") 이후로, tcf_proto_lookup_ops()가 request_module()을 호출하기 위해 RTNL을 해제할 수 있으므로 RTM_NEWCHAIN에 대해 해당 레이블이 필요합니다.
그러나 RTM_GETCHAIN에는 재전송 로직이 필요하지 않습니다.
RTM_NEWCHAIN에만 재전송 로직을 적용합니다.
[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 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>
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.