CVE-2026-98646
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A Linux kernel networking bug can make the system unstable or report errors when certain network monitoring tools are running.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The flaw allows cond_resched() to be invoked from within an RCU read-side critical section during bpf_sock_destroy() on TCP listener sockets that still hold child connections in the accept queue, violating atomic context rules and triggering a kernel debug assertion in inet_csk_listen_stop().
Why it matters to the business
Systems running affected kernel versions may experience unexpected warnings, crashes, or instability when BPF-based network introspection or iterator programs are active, potentially disrupting services that rely on custom socket monitoring or automated cleanup logic.
How an attack unfolds
An attacker or unprivileged user loads a BPF iterator program that walks TCP sockets and calls bpf_sock_destroy on a listening socket; the subsequent tcp_abort path reaches inet_csk_listen_stop while still holding rcu_read_lock, causing the scheduler check to fire and surface the bug.
How to fix it
Upgrade to a kernel containing the referenced fix that guards the cond_resched call with has_current_bpf_ctx(). Apply the vendor-supplied update as soon as it becomes available for the distribution in use.
How to confirm the fix worked
Confirm the patch is present by inspecting the inet_csk_listen_stop source for the has_current_bpf_ctx() guard around cond_resched, then re-run the reproducer BPF program under the same conditions and verify the BUG no longer occurs.
Typical attack path
- Obtain ability to load or attach BPF programs (CAP_BPF or equivalent)
- Attach an iterator that enumerates TCP sockets and invokes sock destroy on listeners
- Trigger the iterator while the listener still has queued child sockets
- Observe the sleeping-function-in-atomic-context BUG report or resulting kernel panic
How to detect it
Search kernel logs for the exact BUG string referencing inet_connection_sock.c and inet_csk_listen_stop, and review audit or BPF load events for recent attachment of iterator programs that enumerate TCP sockets.
What your security team should do
- Prioritize kernel updates on any hosts that load untrusted or broad-scope BPF iterators
- Audit existing BPF programs for use of bpf_sock_destroy on TCP listeners
- Temporarily restrict CAP_BPF to trusted processes until patches are deployed
The record
In the Linux kernel, the following vulnerability has been resolved: tcp: Skip cond_resched() in inet_csk_listen_stop() under BPF context bpf_sock_destroy() runs from the tcp iterator, under rcu_read_lock(). If the sock is a listener that still has children in its accept queue, tcp_abort() ends up in inet_csk_listen_stop() and the cond_resched() there trips the debug check: BUG: sleeping function called from invalid context at net/ipv4/inet_connection_sock.c:1523 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 628, name: test_progs preempt_count: 0, expected: 0 RCU nest depth: 1, expected: 0 locks held by test_progs/628: 3, last CPU#3: #0: ffff8881158cee18 (&p->lock){+.+.}-{4:4}, at: bpf_seq_read+0x56/0x1210 #1: ffff8881106bb858 (sk_lock-AF_INET6){+.+.}-{0:0}, at: bpf_iter_tcp_seq_show+0x32b/0x4b0 #2: ffffffffb435af20 (rcu_read_lock){....}-{1:3}, at: bpf_iter_run_prog+0x46b/0xde0 CPU: 3 UID: 0 PID: 628 Comm: test_progs Tainted: G W 7.2.0+ #65 PREEMPT Tainted: [W]=WARN Call Trace: <TASK> dump_stack_lvl+0xc1/0xf0 dump_stack+0x10/0x20 __might_resched+0x3d2/0x610 inet_csk_listen_stop+0x7b/0xbf0 tcp_abort+0x23b/0x3b0 bpf_sock_destroy+0xfc/0x140 bpf_prog_448133d24601754f_iter_tcp6_server+0x81/0x8a bpf_iter_run_prog+0x538/0xde0 bpf_iter_tcp_seq_show+0x26b/0x4b0 bpf_seq_read+0x424/0x1210 vfs_read+0x197/0xe40 ksys_read+0x119/0x240 __x64_sys_read+0x72/0xc0 x64_sys_call+0x647/0x27e0 do_syscall_64+0xe5/0x610 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fad39b28aca RSP: 002b:00007ffc381c61c0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007ffc381c6a88 RCX: 00007fad39b28aca RDX: 0000000000000032 RSI: 00007ffc381c6250 RDI: 0000000000000014 RBP: 00007ffc381c61e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003 R13: 0000000000000000 R14: 000055f077c1bbb0 R15: 00007fad3a0f3000 </TASK> The commit that added the kfunc already guards lock_sock() in tcp_abort() and udp_abort() with has_current_bpf_ctx(), but missed the listener path. Do the same for the cond_resched(). The loop runs inside the iterator's rcu_read_lock(), it must not reschedule or report a quiescent state there.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|