{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:11",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.180-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.100-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.1.5-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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: \terr = io_wait_event_killable(req-\u003ewq, ...) \t/* SIGKILL wakes the task, returns -ERESTARTSYS */  \tif (err == -ERESTARTSYS \u0026\u0026 c-\u003estatus == Connected \u0026\u0026 \t\ttype == P9_TFLUSH) { \t\tsigpending = 1; \t\tclear_thread_flag(TIF_SIGPENDING); \t\tgoto again; \t}  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:  \u003cTASK\u003e  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  \u003c/TASK\u003e  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.",
  "id": "DEBIAN-CVE-2026-72166",
  "modified": "2026-08-17T08:47:26.555859127Z",
  "published": "2026-08-15T06:21:34.620Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-72166"
    }
  ],
  "upstream": [
    "CVE-2026-72166"
  ]
}