{"api_version":"1","generated_at":"2026-08-15T16:26:27+00:00","cve":"CVE-2026-72166","urls":{"html":"https://cve.report/CVE-2026-72166","api":"https://cve.report/api/cve/CVE-2026-72166.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-72166","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-72166"},"summary":{"title":"net/9p: fix infinite loop in p9_client_rpc on fatal signal","description":"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->wq, ...)\n\t/* SIGKILL wakes the task, returns -ERESTARTSYS */\n\n\tif (err == -ERESTARTSYS && c->status == 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 <TASK>\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 </TASK>\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.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-08-15 06:21:34","updated_at":"2026-08-15 06:21:34"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/4f621ae3a2d99b0bac50e8d66cbf7f68323c01e8","name":"https://git.kernel.org/stable/c/4f621ae3a2d99b0bac50e8d66cbf7f68323c01e8","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/dc892cbb1e4341d427b1f940ebd6abd69bf8e479","name":"https://git.kernel.org/stable/c/dc892cbb1e4341d427b1f940ebd6abd69bf8e479","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/f62a1f245a71680033260a6f6d74011cc3acb3cd","name":"https://git.kernel.org/stable/c/f62a1f245a71680033260a6f6d74011cc3acb3cd","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/a8874c34c4a973f9922908a4b8be1d1278f01e42","name":"https://git.kernel.org/stable/c/a8874c34c4a973f9922908a4b8be1d1278f01e42","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/823886a1b089b49bcd349bc8bd3417b7910cd1ac","name":"https://git.kernel.org/stable/c/823886a1b089b49bcd349bc8bd3417b7910cd1ac","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/6b4f48728faa8bb514368f7eacda05565dea8696","name":"https://git.kernel.org/stable/c/6b4f48728faa8bb514368f7eacda05565dea8696","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/378481cc60a937ef8ea4ef6e4f95f0dbc4e21414","name":"https://git.kernel.org/stable/c/378481cc60a937ef8ea4ef6e4f95f0dbc4e21414","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-72166","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-72166","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad 378481cc60a937ef8ea4ef6e4f95f0dbc4e21414 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad 4f621ae3a2d99b0bac50e8d66cbf7f68323c01e8 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad f62a1f245a71680033260a6f6d74011cc3acb3cd git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad dc892cbb1e4341d427b1f940ebd6abd69bf8e479 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad a8874c34c4a973f9922908a4b8be1d1278f01e42 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad 823886a1b089b49bcd349bc8bd3417b7910cd1ac git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad 6b4f48728faa8bb514368f7eacda05565dea8696 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 2.6.28","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 2.6.28 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 5.15.212 5.15.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.1.178 6.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.6.145 6.6.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.97 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.40 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.1.5 7.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["net/9p/client.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"378481cc60a937ef8ea4ef6e4f95f0dbc4e21414","status":"affected","version":"91b8534fa8f5e01f249b1bf8df0a2540053549ad","versionType":"git"},{"lessThan":"4f621ae3a2d99b0bac50e8d66cbf7f68323c01e8","status":"affected","version":"91b8534fa8f5e01f249b1bf8df0a2540053549ad","versionType":"git"},{"lessThan":"f62a1f245a71680033260a6f6d74011cc3acb3cd","status":"affected","version":"91b8534fa8f5e01f249b1bf8df0a2540053549ad","versionType":"git"},{"lessThan":"dc892cbb1e4341d427b1f940ebd6abd69bf8e479","status":"affected","version":"91b8534fa8f5e01f249b1bf8df0a2540053549ad","versionType":"git"},{"lessThan":"a8874c34c4a973f9922908a4b8be1d1278f01e42","status":"affected","version":"91b8534fa8f5e01f249b1bf8df0a2540053549ad","versionType":"git"},{"lessThan":"823886a1b089b49bcd349bc8bd3417b7910cd1ac","status":"affected","version":"91b8534fa8f5e01f249b1bf8df0a2540053549ad","versionType":"git"},{"lessThan":"6b4f48728faa8bb514368f7eacda05565dea8696","status":"affected","version":"91b8534fa8f5e01f249b1bf8df0a2540053549ad","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["net/9p/client.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"2.6.28"},{"lessThan":"2.6.28","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"5.15.*","status":"unaffected","version":"5.15.212","versionType":"semver"},{"lessThanOrEqual":"6.1.*","status":"unaffected","version":"6.1.178","versionType":"semver"},{"lessThanOrEqual":"6.6.*","status":"unaffected","version":"6.6.145","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.97","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.40","versionType":"semver"},{"lessThanOrEqual":"7.1.*","status":"unaffected","version":"7.1.5","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.2-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"5.15.212","versionStartIncluding":"2.6.28","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.1.178","versionStartIncluding":"2.6.28","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.6.145","versionStartIncluding":"2.6.28","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.97","versionStartIncluding":"2.6.28","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.40","versionStartIncluding":"2.6.28","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.1.5","versionStartIncluding":"2.6.28","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2-rc1","versionStartIncluding":"2.6.28","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"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->wq, ...)\n\t/* SIGKILL wakes the task, returns -ERESTARTSYS */\n\n\tif (err == -ERESTARTSYS && c->status == 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 <TASK>\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 </TASK>\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."}],"providerMetadata":{"dateUpdated":"2026-08-15T05:53:33.383Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/378481cc60a937ef8ea4ef6e4f95f0dbc4e21414"},{"url":"https://git.kernel.org/stable/c/4f621ae3a2d99b0bac50e8d66cbf7f68323c01e8"},{"url":"https://git.kernel.org/stable/c/f62a1f245a71680033260a6f6d74011cc3acb3cd"},{"url":"https://git.kernel.org/stable/c/dc892cbb1e4341d427b1f940ebd6abd69bf8e479"},{"url":"https://git.kernel.org/stable/c/a8874c34c4a973f9922908a4b8be1d1278f01e42"},{"url":"https://git.kernel.org/stable/c/823886a1b089b49bcd349bc8bd3417b7910cd1ac"},{"url":"https://git.kernel.org/stable/c/6b4f48728faa8bb514368f7eacda05565dea8696"}],"title":"net/9p: fix infinite loop in p9_client_rpc on fatal signal","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-72166","datePublished":"2026-08-15T05:53:33.383Z","dateReserved":"2026-08-09T03:40:39.909Z","dateUpdated":"2026-08-15T05:53:33.383Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-08-15 06:21:34","lastModifiedDate":"2026-08-15 06:21:34","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"72166","Ordinal":"1","Title":"net/9p: fix infinite loop in p9_client_rpc on fatal signal","CVE":"CVE-2026-72166","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"72166","Ordinal":"1","NoteData":"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->wq, ...)\n\t/* SIGKILL wakes the task, returns -ERESTARTSYS */\n\n\tif (err == -ERESTARTSYS && c->status == 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 <TASK>\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 </TASK>\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.","Type":"Description","Title":"net/9p: fix infinite loop in p9_client_rpc on fatal signal"}]}}}