CVE-2026-72166: net/9p: fix infinite loop in p9_client_rpc on fatal signal

In the Linux kernel, the following vulnerability has been resolved:

net/9p: fix infinite loop in p9clientrpc on fatal signal

When p9clientrpc() is called with type P9TFLUSH 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 = iowaiteventkillable(req->wq, ...) / SIGKILL wakes the task, returns -ERESTARTSYS /

if (err == -ERESTARTSYS && c->status == Connected && type == P9TFLUSH) { sigpending = 1; clearthreadflag(TIFSIGPENDING); goto again; }

clearthreadflag() clears TIFSIGPENDING before jumping back to iowaiteventkillable(). signalpendingstate() checks TIFSIGPENDING, finds it zero, and the task goes to sleep again. The task can only wake on the next signal delivery that calls signalwakeup() and sets TIFSIGPENDING again. When that happens the loop repeats, clears TIFSIGPENDING, and sleeps again indefinitely.

This is triggered in practice by coredumpwait(): when a thread in a multi-threaded process causes a coredump (e.g. via SIGSYS from Syscall User Dispatch), coredumpwait() sends SIGKILL to all other threads and waits for them to call mmrelease(). If one of those threads is blocked in p9clientrpc() over an fd transport with no peer, it enters the P9TFLUSH loop and never calls mmrelease(), so coredumpwait() 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> contextswitch kernel/sched/core.c:5344 [inline] schedule+0xcb4/0x5d50 kernel/sched/core.c:6724 scheduleloop kernel/sched/core.c:6801 [inline] schedule+0xe5/0x350 kernel/sched/core.c:6816 scheduletimeout+0x253/0x290 kernel/time/timer.c:2593 dowaitforcommon kernel/sched/completion.c:95 [inline] waitforcommon+0x409/0x600 kernel/sched/completion.c:116 waitforcommon kernel/sched/completion.c:127 [inline] waitforcompletionstate+0x1d/0x40 kernel/sched/completion.c:264 coredumpwait fs/coredump.c:448 [inline] docoredump+0x854/0x4350 fs/coredump.c:629 getsignal+0x1425/0x2730 kernel/signal.c:2903 archdosignalorrestart+0x81/0x880 arch/x86/kernel/signal.c:337 exittousermodeloop kernel/entry/common.c:111 [inline] exittousermodeprepare include/linux/entry-common.h:328 [inline] syscallexittousermodework kernel/entry/common.c:207 [inline] syscallexittousermode+0xf9/0x160 kernel/entry/common.c:218 dosyscall64+0x102/0x220 arch/x86/entry/common.c:84 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

Fix: check fatalsignalpending() before clearing TIFSIGPENDING in the P9TFLUSH retry loop. At that point TIFSIGPENDING is still set, so fatalsignalpending() works correctly. If a fatal signal is pending, jump to recalcsigpending to restore TIFSIGPENDING 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. killandwait() 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.