{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-72166 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-72166 is a denial of service vulnerability in Linux, published on 15 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-72166 and fix it if it is affected.\n\nWhat it is: CVE-2026-72166 is a denial of service vulnerability in Linux, published on 15 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-72166 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-72166/ (Markdown: https://insights.sbomify.com/CVE-2026-72166/index.md)","id":"CVE-2026-72166","markdown":"https://insights.sbomify.com/CVE-2026-72166/index.md","name":"CVE-2026-72166","record":{"aliases":["BELL-CVE-2026-72166","DEBIAN-CVE-2026-72166","GHSA-m993-rm7r-56rw","UBUNTU-CVE-2026-72166"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel","requires_auth":"none","summary":"A local attacker can cause a system hang by triggering an infinite loop in the 9p client RPC handler during coredump operations.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"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-\u003ewq, ...)\n\t/* SIGKILL wakes the task, returns -ERESTARTSYS */\n\n\tif (err == -ERESTARTSYS \u0026\u0026 c-\u003estatus == Connected \u0026\u0026\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.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"net/9p: fix infinite loop in p9_client_rpc on fatal signal","id":"CVE-2026-72166","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"denial_of_service","year":"2026"},"n_packages":0,"n_references":8,"next":{"headline":"mtd: rawnand: pl353: fix probe resource allocation","id":"CVE-2026-72167"},"packages":[],"prev":{"headline":"mtd: rawnand: fix condition in 'nand_select_target()'","id":"CVE-2026-72165"},"products":["Linux"],"published":"2026-08-15","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-08-23","vendors":["Linux"]},"summary":"A local attacker can cause a system hang by triggering an infinite loop in the 9p client RPC handler during coredump operations.","url":"https://insights.sbomify.com/CVE-2026-72166/"}