CVE-2026-72166 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
net/9p: fix infinite loop in p9_client_rpc on fatal signal
When p9_client_rpc() is called with type P9_TFLUSH and the transport has no peer (e.g. fd transport backed by pipes with no 9p server), a fatal signal causes an infinite loop:
again: err = io_wait_event_killable(req->wq, ...) /* SIGKILL wakes the task, returns -ERESTARTSYS */
if (err == -ERESTARTSYS && c->status == Connected && type == P9_TFLUSH) {
sigpending = 1; clear_thread_flag(TIF_SIGPENDING); goto again; }
clear_thread_flag() clears TIF_SIGPENDING before jumping back to io_wait_event_killable(). signal_pending_state() checks TIF_SIGPENDING, finds it zero, and the task goes to sleep again. The task can only wake on the next signal delivery that calls signal_wake_up() and sets TIF_SIGPENDING again. When that happens the loop repeats, clears TIF_SIGPENDING, and sleeps again indefinitely.
This is triggered in practice by coredump_wait(): when a thread in a multi-threaded process causes a coredump (e.g. via SIGSYS from Syscall User Dispatch), coredump_wait() sends SIGKILL to all other threads and waits for them to call mm_release(). If one of those threads is blocked in p9_client_rpc() over an fd transport with no peer, it enters the P9_TFLUSH loop and never calls mm_release(), so coredump_wait() stalls forever:
INFO: task syz.0.18:676 blocked for more than 143 seconds. Not tainted 6.12.77+ #1 task:syz.0.18 state:D stack:27600 pid:676 tgid:673 ppid:630 flags:0x00000004 Call Trace: <TASK> context_switch kernel/sched/core.c:5344 [inline]
__schedule+0xcb4/0x5d50 kernel/sched/core.c:6724 __schedule_loop kernel/sched/core.c:6801 [inline]
schedule+0xe5/0x350 kernel/sched/core.c:6816 schedule_timeout+0x253/0x290 kernel/time/timer.c:2593 do_wait_for_common kernel/sched/completion.c:95 [inline]
__wait_for_common+0x409/0x600 kernel/sched/completion.c:116 wait_for_common kernel/sched/completion.c:127 [inline]
wait_for_completion_state+0x1d/0x40 kernel/sched/completion.c:264 coredump_wait fs/coredump.c:448 [inline]
do_coredump+0x854/0x4350 fs/coredump.c:629 get_signal+0x1425/0x2730 kernel/signal.c:2903 arch_do_signal_or_restart+0x81/0x880 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]
__syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
syscall_exit_to_user_mode+0xf9/0x160 kernel/entry/common.c:218 do_syscall_64+0x102/0x220 arch/x86/entry/common.c:84 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
Fix: check fatal_signal_pending() before clearing TIF_SIGPENDING in the P9_TFLUSH retry loop. At that point TIF_SIGPENDING is still set, so fatal_signal_pending() works correctly. If a fatal signal is pending, jump to recalc_sigpending to restore TIF_SIGPENDING and return -ERESTARTSYS to the caller.
The same defect is present in stable kernels back to 5.4. On those kernels the infinite loop is broken earlier by a second SIGKILL from the parent process (e.g. kill_and_wait() retrying after a timeout), resulting in a zombie process and a shutdown delay rather than a permanent D-state hang, but the underlying flaw is the same.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability described represents a critical race condition and infinite loop scenario within the Linux kernel's 9P protocol implementation, specifically affecting the p9_client_rpc function when handling P9_TFLUSH requests under certain signal conditions. This flaw exists in the network file system subsystem and manifests when a client attempts to flush operations while communicating over an fd transport that lacks a connected peer, such as pipes without a corresponding 9P server. The issue originates from how the kernel handles signal delivery and task scheduling during asynchronous I/O operations, creating a pathological state where a thread becomes indefinitely blocked in a retry loop.
The technical mechanism behind this vulnerability involves the interaction between signal handling and I/O waiting mechanisms within the kernel's event loop. When p9_client_rpc() processes a P9_TFLUSH request with no transport peer, it enters a retry loop that calls io_wait_event_killable() to wait for completion. A fatal signal such as SIGKILL causes the wait operation to return -ERESTARTSYS, which triggers a conditional check in the code path. The problematic sequence occurs when clear_thread_flag(TIF_SIGPENDING) is called before jumping back to the io_wait_event_killable() call, effectively clearing the signal pending flag that would normally wake the task from sleep. This creates a condition where signal_pending_state() finds no pending signals and the thread remains indefinitely asleep, only to be awakened by subsequent signal deliveries that again trigger the same clearing and sleeping cycle.
This vulnerability directly impacts system stability and resource management through its interaction with the coredump_wait() mechanism used during process termination. When a multi-threaded process generates a core dump due to signals like SIGSYS from syscall user dispatch, the coredump_wait() function sends SIGKILL to all threads and waits for them to call mm_release(). If one of these threads is blocked in p9_client_rpc() over an fd transport with no peer, it becomes trapped in the infinite loop described above, preventing the mm_release() call from being made. This creates a deadlock scenario where coredump_wait() cannot proceed because the blocked thread never exits its wait state, leading to system-wide stalls and potential DoS conditions.
The fix implemented addresses this by introducing an additional check for fatal_signal_pending() before clearing the TIF_SIGPENDING flag in the retry loop. This ensures that when a fatal signal is detected, the code properly transitions to recalc_sigpending() which restores the signal pending flag and returns -ERESTARTSYS to the caller, allowing the calling function to properly handle the signal and exit the blocking state. This solution aligns with the principles of proper signal handling in kernel space as outlined in security best practices for Linux kernel development.
This vulnerability is classified under CWE-835: Loop with Unreachable Exit Condition (Infinite Loop) and demonstrates a classic example of improper signal handling in kernel contexts, which can be mapped to ATT&CK technique T1490: Inhibit System Recovery. The flaw affects multiple kernel versions from 5.4 onwards and represents a long-standing issue that was made more apparent by the increased use of coredump mechanisms and multi-threaded applications. The detection through Syzkaller and the Linux Verification Center highlights the importance of automated testing in identifying subtle race conditions and state management issues in kernel code, particularly those involving signal handling and asynchronous I/O operations.
The broader implications of this vulnerability extend beyond simple system hangs to potentially enable denial-of-service attacks against systems running 9P clients, especially in environments where multiple threads may be simultaneously accessing network file systems. The presence of this issue across such a wide range of kernel versions indicates that it represents a fundamental flaw in how the 9P protocol implementation handles edge cases with signal delivery and task synchronization. System administrators should prioritize updating affected kernels to prevent potential exploitation through carefully crafted workloads that can trigger the specific conditions leading to this infinite loop state.
The vulnerability's resolution demonstrates the complexity of kernel-level signal handling, where seemingly simple flag operations can create cascading effects that lead to system-wide stability issues. The fix specifically addresses the root cause by ensuring proper signal state management during retry loops, preventing the scenario where a thread becomes permanently blocked in kernel space due to improper interaction between task scheduling and signal delivery mechanisms. This represents a critical lesson in kernel development about the importance of maintaining consistent signal state across retry loops and asynchronous operations, particularly in file system implementations that may be subject to various process termination scenarios including core dump generation.