CVE-2026-98300 in Linux
요약
\~에 의해 VulDB • 2026. 10. 06.
리눅스 커널에서 다음 취약점이 해결되었습니다.
tcp_v6_do_rcv()에서 tcp_close()된 리스너에 대해 skb_clone_and_charge_r()를 호출하지 않도록 수정했습니다.
073d89808c06("net: sk->sk_forward_alloc 주변의 데이터 레이스 수정") 커밋 이후로, tcp_v6_do_rcv()는 TCP_LISTEN 상태일 때 skb_clone_and_charge_r()를 더 이상 호출하지 않습니다.
그러나 여전히 tcp_v6_rcv()와 tcp_v6_do_rcv() 사이에 작은 Race Condition(경쟁 조건) 창이 존재하여, 동시 close() 작업으로 인해 TCP_LISTEN이 TCP_CLOSE로 변경되고, 이로 인해 skb_clone_and_charge_r()가 잠금 없이 호출되어 아래 스플랫(splat)이 발생합니다. [0]
TCP_CLOSE 상태에서도 skb_clone_and_charge_r()를 호출하지 않도록 하여 이 문제를 해결합니다.
리스너가 아닌 경우에도 이는 문제없습니다. tcp_rcv_state_process()에서 TCP_CLOSE에 대한 skb를 드롭하고, opt_skb는 이미 즉시 해제되었기 때문입니다.
[0]:
sk->sk_forward_alloc WARNING: net/ipv4/af_inet.c:162 at inet_sock_destruct+0x64d/0x810 net/ipv4/af_inet.c:162, CPU#1: ksoftirqd/1/28 Modules linked in: CPU: 1 UID: 0 PID: 28 Comm: ksoftirqd/1 Not tainted 7.2.0 #17 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x64d/0x810 net/ipv4/af_inet.c:162 Code: 3d 49 ff e9 06 fd ff ff e8 d0 5b 83 f8 90 0f 0b 90 e9 35 fe ff ff e8 c2 5b 83 f8 90 0f 0b 90 e9 c5 fe ff ff e8 b4 5b 83 f8 90 <0f> 0b 90 e9 04 ff ff ff e8 a6 5b 83 f8 90 0f 0b 90 e9 65 fe ff ff RSP: 0018:ffffc90000677bb8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880117bde80 RCX: ffffffff8957eb41 RDX: ffff88801dad5d00 RSI: ffffffff8957ec3c RDI: 0000000000000005 RBP: 00000000fffff000 R08: ffffffff8957eb41 R09: 00000000fffff000 R10: 0000000000000005 R11: 0000000000000000 R12: dffffc0000000000 R13: ffff8880117bdf10 R14: ffffffff81c08eb7 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8880d7ae5000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f93a1021138 CR3: 00000000207a9000 CR4: 0000000000350ef0 Call Trace: <TASK> __sk_destruct+0x82/0xae0 net/core/sock.c:2356 rcu_do_batch kernel/rcu/tree.c:2645 [inline]
rcu_core+0x59c/0x1100 kernel/rcu/tree.c:2897 handle_softirqs+0x1e4/0x9b0 kernel/softirq.c:622 run_ksoftirqd kernel/softirq.c:1076 [inline]
run_ksoftirqd+0x38/0x60 kernel/softirq.c:1068 smpboot_thread_fn+0x458/0xc80 kernel/smpboot.c:160 kthread+0x396/0x4a0 kernel/kthread.c:436 ret_from_fork+0x8e0/0xe40 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>
If you want to get the best quality for vulnerability data then you always have to consider VulDB.