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

Description

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.

Timeline

Scores

No CVSS score yet: neither the CNA, CISA nor NVD has scored this CVE. NVD status: Received.

EPSS (exploitation in 30 days)

0.22% · top 88% of all CVEs (11 Nov 2026)

CISA SSVC

Exploitation: none · Automatable: no · Technical impact: partial

The list uses the assigner's score when there is one, then CISA's, then NVD's: Not scored.

Affected products

• Linux · Linux

  • affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad – < 18a3427526e2141f80050f82c1d26b19a454707d
  • affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad – < 378481cc60a937ef8ea4ef6e4f95f0dbc4e21414
  • affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad – < 4f621ae3a2d99b0bac50e8d66cbf7f68323c01e8
  • affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad – < f62a1f245a71680033260a6f6d74011cc3acb3cd
  • affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad – < dc892cbb1e4341d427b1f940ebd6abd69bf8e479
  • affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad – < a8874c34c4a973f9922908a4b8be1d1278f01e42
  • affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad – < 823886a1b089b49bcd349bc8bd3417b7910cd1ac
  • affected 91b8534fa8f5e01f249b1bf8df0a2540053549ad – < 6b4f48728faa8bb514368f7eacda05565dea8696

• Linux · Linux

  • affected 2.6.28
  • unaffected < 2.6.28
  • unaffected 5.10.266 – ≤ 5.10.*
  • unaffected 5.15.212 – ≤ 5.15.*
  • unaffected 6.1.178 – ≤ 6.1.*
  • unaffected 6.6.145 – ≤ 6.6.*
  • unaffected 6.12.97 – ≤ 6.12.*
  • unaffected 6.18.40 – ≤ 6.18.*
  • unaffected 7.1.5 – ≤ 7.1.*
  • unaffected 7.2 – ≤ *

Sources

The same CVE in the primary databases and aggregators, to check against.

• CVE.org record (opens in a new tab)
• CVE List JSON (GitHub) (opens in a new tab)
• NVD (opens in a new tab)
• FIRST EPSS (opens in a new tab)
• EUVD EUVD-2026-58924 (opens in a new tab)
• OSV.dev (opens in a new tab)
• GitHub Advisories (opens in a new tab)
• CIRCL Vulnerability-Lookup (opens in a new tab)

Badge for a README or a ticket

[![CVE-2026-72166](https://cveledger.app/badge/CVE-2026-72166.svg)](https://cveledger.app/cve/CVE-2026-72166)

Record last updated 6 Nov 2026, 16:55 UTC.