{"id":"CVE-2026-72166","summary":"net/9p: fix infinite loop in p9_client_rpc on fatal signal","details":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/9p: fix infinite loop in p9_client_rpc on fatal signal\n\nWhen p9_client_rpc() is called with type P9_TFLUSH and the transport\nhas no peer (e.g. fd transport backed by pipes with no 9p server),\na fatal signal causes an infinite loop:\n\n  again:\n\terr = io_wait_event_killable(req-\u003ewq, ...)\n\t/* SIGKILL wakes the task, returns -ERESTARTSYS */\n\n\tif (err == -ERESTARTSYS && c-\u003estatus == Connected &&\n\t\ttype == P9_TFLUSH) {\n\t\tsigpending = 1;\n\t\tclear_thread_flag(TIF_SIGPENDING);\n\t\tgoto again;\n\t}\n\nclear_thread_flag() clears TIF_SIGPENDING before jumping back to\nio_wait_event_killable(). signal_pending_state() checks TIF_SIGPENDING,\nfinds it zero, and the task goes to sleep again. The task can only wake\non the next signal delivery that calls signal_wake_up() and sets\nTIF_SIGPENDING again. When that happens the loop repeats, clears\nTIF_SIGPENDING, and sleeps again indefinitely.\n\nThis is triggered in practice by coredump_wait(): when a thread in a\nmulti-threaded process causes a coredump (e.g. via SIGSYS from Syscall\nUser Dispatch), coredump_wait() sends SIGKILL to all other threads and\nwaits for them to call mm_release(). If one of those threads is blocked\nin p9_client_rpc() over an fd transport with no peer, it enters the\nP9_TFLUSH loop and never calls mm_release(), so coredump_wait() stalls\nforever:\n\nINFO: task syz.0.18:676 blocked for more than 143 seconds.\n      Not tainted 6.12.77+ #1\ntask:syz.0.18 state:D stack:27600 pid:676 tgid:673 ppid:630 flags:0x00000004\nCall Trace:\n \u003cTASK\u003e\n context_switch kernel/sched/core.c:5344 [inline]\n __schedule+0xcb4/0x5d50 kernel/sched/core.c:6724\n __schedule_loop kernel/sched/core.c:6801 [inline]\n schedule+0xe5/0x350 kernel/sched/core.c:6816\n schedule_timeout+0x253/0x290 kernel/time/timer.c:2593\n do_wait_for_common kernel/sched/completion.c:95 [inline]\n __wait_for_common+0x409/0x600 kernel/sched/completion.c:116\n wait_for_common kernel/sched/completion.c:127 [inline]\n wait_for_completion_state+0x1d/0x40 kernel/sched/completion.c:264\n coredump_wait fs/coredump.c:448 [inline]\n do_coredump+0x854/0x4350 fs/coredump.c:629\n get_signal+0x1425/0x2730 kernel/signal.c:2903\n arch_do_signal_or_restart+0x81/0x880 arch/x86/kernel/signal.c:337\n exit_to_user_mode_loop kernel/entry/common.c:111 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0xf9/0x160 kernel/entry/common.c:218\n do_syscall_64+0x102/0x220 arch/x86/entry/common.c:84\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u003c/TASK\u003e\n\nFix: check fatal_signal_pending() before clearing TIF_SIGPENDING in the\nP9_TFLUSH retry loop. At that point TIF_SIGPENDING is still set, so\nfatal_signal_pending() works correctly. If a fatal signal is pending,\njump to recalc_sigpending to restore TIF_SIGPENDING and return\n-ERESTARTSYS to the caller.\n\nThe same defect is present in stable kernels back to 5.4. On those\nkernels the infinite loop is broken earlier by a second SIGKILL from\nthe parent process (e.g. kill_and_wait() retrying after a timeout),\nresulting in a zombie process and a shutdown delay rather than a\npermanent D-state hang, but the underlying flaw is the same.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.","modified":"2026-08-18T03:30:50.425246539Z","published":"2026-08-15T05:53:33.383Z","database_specific":{"cna_assigner":"Linux","osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72166.json"},"references":[{"type":"WEB","url":"https://git.kernel.org/stable/c/378481cc60a937ef8ea4ef6e4f95f0dbc4e21414"},{"type":"WEB","url":"https://git.kernel.org/stable/c/4f621ae3a2d99b0bac50e8d66cbf7f68323c01e8"},{"type":"WEB","url":"https://git.kernel.org/stable/c/6b4f48728faa8bb514368f7eacda05565dea8696"},{"type":"WEB","url":"https://git.kernel.org/stable/c/823886a1b089b49bcd349bc8bd3417b7910cd1ac"},{"type":"WEB","url":"https://git.kernel.org/stable/c/a8874c34c4a973f9922908a4b8be1d1278f01e42"},{"type":"WEB","url":"https://git.kernel.org/stable/c/dc892cbb1e4341d427b1f940ebd6abd69bf8e479"},{"type":"WEB","url":"https://git.kernel.org/stable/c/f62a1f245a71680033260a6f6d74011cc3acb3cd"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/72xxx/CVE-2026-72166.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72166"},{"type":"PACKAGE","url":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","events":[{"introduced":"91b8534fa8f5e01f249b1bf8df0a2540053549ad"},{"fixed":"378481cc60a937ef8ea4ef6e4f95f0dbc4e21414"},{"fixed":"4f621ae3a2d99b0bac50e8d66cbf7f68323c01e8"},{"fixed":"f62a1f245a71680033260a6f6d74011cc3acb3cd"},{"fixed":"dc892cbb1e4341d427b1f940ebd6abd69bf8e479"},{"fixed":"a8874c34c4a973f9922908a4b8be1d1278f01e42"},{"fixed":"823886a1b089b49bcd349bc8bd3417b7910cd1ac"},{"fixed":"6b4f48728faa8bb514368f7eacda05565dea8696"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-72166.json"}},{"package":{"name":"Kernel","ecosystem":"Linux"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.6.28"},{"fixed":"5.15.212"}]},{"type":"ECOSYSTEM","events":[{"introduced":"5.16.0"},{"fixed":"6.1.178"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.2.0"},{"fixed":"6.6.145"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.7.0"},{"fixed":"6.12.97"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.13.0"},{"fixed":"6.18.40"}]},{"type":"ECOSYSTEM","events":[{"introduced":"6.19.0"},{"fixed":"7.1.5"}]}],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-72166.json"}}],"schema_version":"1.9.0"}