FKIE_CVE-2026-72166
Vulnerability from fkie_nvd - Published: 2026-08-15 06:21 - Updated: 2026-08-23 13:16
Severity
Summary
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.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"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": "18a3427526e2141f80050f82c1d26b19a454707d",
"status": "affected",
"version": "91b8534fa8f5e01f249b1bf8df0a2540053549ad",
"versionType": "git"
},
{
"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.10.*",
"status": "unaffected",
"version": "5.10.266",
"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",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"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-\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."
}
],
"id": "CVE-2026-72166",
"lastModified": "2026-08-23T13:16:41.120",
"metrics": {},
"published": "2026-08-15T06:21:34.620",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/18a3427526e2141f80050f82c1d26b19a454707d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/378481cc60a937ef8ea4ef6e4f95f0dbc4e21414"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4f621ae3a2d99b0bac50e8d66cbf7f68323c01e8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/6b4f48728faa8bb514368f7eacda05565dea8696"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/823886a1b089b49bcd349bc8bd3417b7910cd1ac"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a8874c34c4a973f9922908a4b8be1d1278f01e42"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/dc892cbb1e4341d427b1f940ebd6abd69bf8e479"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f62a1f245a71680033260a6f6d74011cc3acb3cd"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.