CVE-2026-98300 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
tcp: Don't call skb_clone_and_charge_r() for close()d listener in tcp_v6_do_rcv().
tcp_v6_do_rcv() no longer calls skb_clone_and_charge_r() for TCP_LISTEN since commit 073d89808c06 ("net: fix data-races around sk->sk_forward_alloc").
However, there is still a small race window between tcp_v6_rcv() and tcp_v6_do_rcv(), where concurrent close() changes TCP_LISTEN to TCP_CLOSE, causing skb_clone_and_charge_r() to be called locklessly and resulting in the splat below. [0]
Let's avoid calling skb_clone_and_charge_r() for TCP_CLOSE as well.
This is fine for non-listeners because tcp_rcv_state_process() drops skb for TCP_CLOSE and opt_skb was freed immediately anyway.
[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>
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel TCP stack contains a race condition vulnerability within the IPv6 receive path that can lead to memory corruption and system instability. The issue resides in the tcp_v6_do_rcv function, which is responsible for processing incoming TCP packets after they have been validated by tcp_v6_rcv. Specifically, the problem arises during the invocation of skb_clone_and_charge_r(), a helper function used to clone socket buffers and charge them against the socket's forward allocation accounting. While previous patches addressed data races related to sk_forward_alloc when handling sockets in the TCP_LISTEN state, they failed to account for the transitional window where a listener socket is being closed concurrently with packet processing.
The root cause of this vulnerability is a timing gap between the initial reception check and the actual state-based processing. When tcp_v6_rcv determines that a packet should be processed by tcp_v6_do_rcv, it assumes the socket remains in a valid receiving state. However, if another thread or interrupt context calls close() on that listener socket during this brief interval, the socket's state transitions from TCP_LISTEN to TCP_CLOSE before tcp_v6_do_rcv executes. The existing code only excluded TCP_LISTEN states from calling skb_clone_and_charge_r(), leaving TCP_CLOSE sockets vulnerable. Consequently, when a packet arrives for a socket in the process of closing, the kernel attempts to charge memory allocation without proper synchronization locks, leading to inconsistent accounting and potential use-after-free scenarios as indicated by the sk_forward_alloc warning in inet_sock_destruct.
This race condition manifests primarily through warnings related to sock destruction routines, specifically triggering alerts within af_inet.c during the cleanup phase of socket structures. The technical impact includes memory corruption due to incorrect reference counting or allocation tracking, which can eventually lead to kernel panics or denial of service conditions where network functionality becomes unstable under high load with frequent connection establishment and teardown cycles. Although non-listener sockets are generally safe because tcp_rcv_state_process drops packets for TCP_CLOSE states immediately, the listener socket path lacks this immediate drop mechanism in the specific code path affected by the race window.
From a classification perspective, this vulnerability aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition). The lack of proper locking around state transitions and resource accounting allows concurrent operations to interfere with each other's assumptions about socket validity. In terms of attack vectors, while exploitation typically requires specific timing conditions often found in high-throughput environments rather than direct remote code execution, it falls under the broader category of availability impacts associated with kernel-level race conditions that can destabilize system resources.
Mitigation for this issue involves applying the upstream Linux kernel patch that extends the exclusion logic to include TCP_CLOSE states alongside TCP_LISTEN when deciding whether to invoke skb_clone_and_charge_r(). System administrators should ensure their kernels are updated to versions containing commit 073d89808c06 and its subsequent fix. For environments where immediate patching is not feasible, reducing connection churn rates or implementing rate limiting on incoming SYN packets can help minimize the window of opportunity for this race condition to trigger. Continuous monitoring of kernel logs for sk_forward_alloc warnings provides an early indicator that such races are occurring in production systems.