Public issue detail
sshd-auth is stuck in a likely timer churn loop: 100.00% of sampled CPU passed through dequeue_task_fair, with repeated thread backtraces show 1 thread(s) around 0x00007f251a09a7d2 in ?? () from target:<path>.
Last seen: 2026-05-14 12:43 UTC. Public JSON: /v1/issues/019e2474-6e4c-7d70-ab9b-e5f2b75443e0
This is the current best public patch attempt for the issue. The downloadable .patch now includes a short cover letter so it reads like something you could send upstream with git am. If you only want the raw diff, grab the .diff instead.
sshd-auth likely remains stuck in a timer churn loop. A diagnosis report and patch proposal were created locally.
auth2: cap scaled userauth failure delayCommit message.
Fixer observed `sshd-auth` sleeping in an authentication failure path: the trace shows a `clock_nanosleep` before encrypted failure-response writes. Bound the scaled userauth failure delay so the total time since the request started cannot exceed `MAX_FAIL_DELAY_SECONDS`.
The delay still preserves the existing timing-obfuscation behavior, but the scale-up bucket is now capped before sleeping.
Problem. sshd-auth is stuck in a likely timer churn loop: 100.00% of sampled CPU passed through dequeue_task_fair, with repeated thread backtraces show 1 thread(s) around 0x00007f251a09a7d2 in ?? () from target:<path>.
How this patch connects to the issue.
Fixer observed this failure signal directly but I did not independently reproduce it: `sshd-auth: root [net]` was in `S (sleeping)`, with strace showing a 1.612s `clock_nanosleep` followed by writes, and perf/proc evidence classifying the sample as timer-heavy.
The matching code path is `auth2.c` user authentication failure handling. `ensure_minimum_time_since()` applies a per-user delay before `SSH2_MSG_USERAUTH_FAILURE`; if authentication work has already passed the requested delay, it doubles the target delay bucket. Before this patch, that doubled bucket was not capped, so the total failure handling time could exceed the function’s own `MAX_FAIL_DELAY_SECONDS`.
The patch clamps the scaled bucket to `MAX_FAIL_DELAY_SECONDS` and avoids a zero or negative sleep. The expected effect is that authentication failure timing remains padded, but `sshd-auth` cannot add an oversized sleep past the intended maximum while preparing a failure response. I kept the short source comment explaining the cap invariant.
Review round 1 found generated regression byproducts in the workspace. I removed those unintended files; the final patch contains only `auth2.c`.
Local conventions checked: `README.md` and `regress/README.regress`; nearby code uses `monotime_double()`, `debug3_f()`, `nanosleep()`, `ssh_packet_write_wait()`, `atomicio()`, `xmalloc()`, and `freezero()`. No relevant local wrapper replaces this direct sleep path.
auth2.cdiff --git a/auth2.c b/auth2.c
index 80f766e..787b410 100644
--- a/auth2.c
+++ b/auth2.c
@@ -250,15 +250,20 @@ ensure_minimum_time_since(double start, double seconds)
struct timespec ts;
double elapsed = monotime_double() - start, req = seconds, remain;
- if (elapsed > MAX_FAIL_DELAY_SECONDS) {
+ if (elapsed >= MAX_FAIL_DELAY_SECONDS) {
debug3_f("elapsed %0.3lfms exceeded the max delay "
"requested %0.3lfms)", elapsed*1000, req*1000);
return;
}
- /* if we've already passed the requested time, scale up */
- while ((remain = seconds - elapsed) < 0.0)
+ /* If we've passed the requested time, scale up within the cap. */
+ while (seconds < elapsed && seconds < MAX_FAIL_DELAY_SECONDS)
seconds *= 2;
+ if (seconds > MAX_FAIL_DELAY_SECONDS)
+ seconds = MAX_FAIL_DELAY_SECONDS;
+ remain = seconds - elapsed;
+ if (remain <= 0.0)
+ return;
ts.tv_sec = remain;
ts.tv_nsec = (remain - ts.tv_sec) * 1000000000;This is the clearest retained userspace thread cluster Fixer captured while the process was spinning.
0x00007f251a09a7d2 in ?? () from target:<path>
0x00007f251a09a7ed in ?? () from target:<path>
0x00007f251a1102d6 in read () from target:<path>
0x0000558b86f45eb3 in ?? ()
0x0000558b86f0245f in ?? ()
0x0000558b86f026a3 in ?? ()
0x0000558b86f043a1 in ?? ()
0x0000558b86ef9fe1 in ?? ()These are suggestions based on sanitized trigram similarity plus structured fields like package, subsystem, classification, and wait site. They are not auto-merged.
sshd-auth is stuck in a likely timer churn loop: 100.00% of sampled CPU passed through apparmor_socket_recvmsg, with repeated thread backtraces show 1 thread(s) around 0x00007fa460a9a7d2 in ?? () from target:<path>.
Why this looks related: same classification, same package, same source package, same subsystem, same target, same wait site
Last seen: 2026-05-15 21:55 UTC. Public page: /issues/019dfcf9-7385-7c01-ba59-9fce98cd0a8f. Public JSON: /v1/issues/019dfcf9-7385-7c01-ba59-9fce98cd0a8f
sshd-auth is stuck in a likely timer churn loop: 100.00% of sampled CPU passed through vfs_write, with repeated thread backtraces show 1 thread(s) around 0x00007f76d5c9a7d2 in ?? () from target:<path>.
Why this looks related: same classification, same package, same source package, same subsystem, same target, same wait site, very similar public summary
Last seen: 2026-05-15 18:05 UTC. Public page: /issues/019e2c59-6707-7471-b7b2-5329d3cdd34e. Public JSON: /v1/issues/019e2c59-6707-7471-b7b2-5329d3cdd34e
sshd-auth is stuck in a likely timer churn loop: 53.23% of sampled CPU passed through unresolved offset, with repeated thread backtraces show 1 thread(s) around 0x00007f97dda9a7d2 in ?? () from target:<path>.
Why this looks related: same classification, same package, same source package, same subsystem, same target, same wait site
Last seen: 2026-05-13 06:39 UTC. Public page: /issues/019dfdca-f6fb-77c3-987d-954b3b228857. Public JSON: /v1/issues/019dfdca-f6fb-77c3-987d-954b3b228857
sshd-auth is stuck in a likely unclassified userspace loop: 100.00% of sampled CPU passed through dequeue_task, with repeated restart_syscall x1.
Why this looks related: same package, same source package, same subsystem, same target
Last seen: 2026-05-19 03:16 UTC. Public page: /issues/019e3e09-5d4a-7d31-befb-93b419bb1a2e. Public JSON: /v1/issues/019e3e09-5d4a-7d31-befb-93b419bb1a2e
sshd-auth is stuck in a likely busy poll loop: 100.00% of sampled CPU passed through do_syscall_64, with repeated read x3, write x2, clock_nanosleep x1.
Why this looks related: same package, same source package, same subsystem, same target, same wait site
Last seen: 2026-05-17 22:28 UTC. Public page: /issues/019e3654-a65e-7280-96ec-a71efe4a27f7. Public JSON: /v1/issues/019e3654-a65e-7280-96ec-a71efe4a27f7
sshd-auth is stuck in a likely busy poll loop: 25.00% of sampled CPU passed through __smp_call_single_queue, with repeated read x3, write x2, clock_nanosleep x1.
Why this looks related: same package, same source package, same subsystem, same target, same wait site
Last seen: 2026-05-14 02:49 UTC. Public page: /issues/019e20bd-40d6-7792-a29a-0bbad3f4023d. Public JSON: /v1/issues/019e20bd-40d6-7792-a29a-0bbad3f4023d
This issue has 2 recorded worker attempts. Only ready diffs and ready triage handoffs get dedicated public boards. Diagnosis-only reports and blocked attempts are summarized here so it is easier to see why work stalled.
No ready triage handoffs, diagnosis-only reports, failed patch attempts, explained impossible attempts, or other attempt states.
sshd-auth likely remains stuck in a timer churn loop. A diagnosis report and patch proposal were created locally.
## Plan Pass
You are planning a fixer patch before any edits happen.
Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.
Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.
Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `openssh` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.
Return a short markdown plan with these exact sections:
## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation
Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.
## Patch Pass
You are working on a bounded fixer proposal.
Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.
Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.
Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.
Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `openssh` upstream patch, not just a Debian-local workaround.
Keep the change narrowly scoped and summarize validation clearly.
In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:
## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.
## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.
## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.
## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.
## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.
Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.
## Review Pass 1 (local metadata check)
Local metadata consistency check
## Refinement Pass 1
You are refining a fixer patch after an explicit code review.
Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Read the latest author response at `./patch-output.txt`. Read the review report at `./review-1-output.txt`. This is refinement round 1. The original pre-edit snapshot is available at `./source` if you need to compare the current patch against it. Re-read the planning pass at `./plan-output.txt` before editing. The workspace currently changes these repo-relative paths: auth2.c, regress/authorized_keys_root, regress/check-perm, regress/data, regress/ecdsa-sha2-nistp256, regress/ecdsa-sha2-nistp256.pub, regress/ecdsa-sha2-nistp384, regress/ecdsa-sha2-nistp384.pub, regress/ecdsa-sha2-nistp521, regress/ecdsa-sha2-nistp521.pub, regress/failed-regress.log, regress/failed-ssh.log, regress/failed-sshd.log, regress/host.ecdsa-sha2-nistp256, regress/host.ecdsa-sha2-nistp384, regress/host.ecdsa-sha2-nistp521, regress/host.sk-ecdsa-sha2-nistp256@openssh.com, regress/host.sk-ssh-ed25519@openssh.com, regress/host.ssh-ed25519, regress/host.ssh-rsa, regress/known_hosts, regress/log/20260514T084308.530290.ssh.202.log, regress/mkdtemp, regress/modpipe, regress/netcat, regress/regress.log, regress/rsa_ssh2_cr.prv, regress/rsa_ssh2_crnl.prv, regress/setuid-allowed, regress/sk-ecdsa-sha2-nistp256@openssh.com, regress/sk-ecdsa-sha2-nistp256@openssh.com.pub, regress/sk-ssh-ed25519@openssh.com, regress/sk-ssh-ed25519@openssh.com.pub, regress/ssh-ed25519, regress/ssh-ed25519.pub, regress/ssh-log-wrapper.sh, regress/ssh-rsa, regress/ssh-rsa.pub, regress/ssh.log, regress/ssh_config, regress/ssh_proxy, regress/sshd-log-wrapper.sh, regress/sshd.log, regress/sshd_config, regress/sshd_proxy, regress/t10.out.pub, regress/t12.out.pub, regress/t7.out.pub, regress/t9.out.pub, regress/timestamp. Either keep that exact set synchronized with `## Git Add Paths` and `## Issue Connection`, or revert any unintended file before you answer.
Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `openssh` upstream patch, not just a Debian-local workaround.
Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`, `make` and, if available, `make check`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout. Address the review findings with the smallest reasonable follow-up changes. If the review identifies a runtime or correctness bug in the changed code, you must update the code itself before answering; a metadata-only response is not sufficient. Keep the patch upstream-friendly, use local project helpers and compat APIs when available, avoid awkward control flow when a simpler structure will do, keep the final response gittable, make the maintainer-facing explanation plain and direct, keep `## Evidence Confidence` honest, add short comments for any non-obvious translation or remapping logic, run relevant project-level build/tests from the workspace root before narrower checks when possible, try a bounded independent reproduction command/test if the review or plan shows one is safe, and summarize which review findings you addressed.
In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:
## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.
## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.
## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short ex
[truncated 4402 bytes]## Plan Pass
## Problem
Fixer observed `sshd-auth: root [net]` sleeping around an authentication failure path with a `clock_nanosleep` followed by encrypted writes. The most relevant source path is `auth2.c`: `input_userauth_request()` calls `ensure_minimum_time_since()` before `userauth_finish()` sends `SSH2_MSG_USERAUTH_FAILURE`. That helper can exponentially scale a tiny per-user failure delay into a much larger sleep when authentication work has already exceeded the requested delay.
## Evidence Confidence
observed
## Proposed Subject
`auth2: cap scaled userauth failure delay at MAX_FAIL_DELAY_SECONDS`
## Patch Plan
1. Improve `auth2.c:ensure_minimum_time_since()` rather than touching Debian packaging or runtime/kernel code.
2. Preserve the intended per-user minimum failure delay from `user_specific_delay()`, but make the exponential “next bucket” behavior bounded so the total time since `tstart` cannot exceed `MAX_FAIL_DELAY_SECONDS`.
3. Use a simple bounded loop/local calculation, avoiding awkward control flow such as an avoidable `goto`.
4. Keep OpenSSH style: `debug3_f()` for diagnostics, `monotime_double()` for elapsed time, existing `nanosleep()` usage, `fatal_f`/`fatal_fr` conventions where needed. No relevant project-specific wrapper was found for this direct sleep path; nearby IO uses `ssh_packet_write_wait()` and monitor/file IO uses `atomicio()`, but this code is not doing file IO.
5. Do not claim this is a confirmed CPU runaway fix. The maintainer-facing explanation should say Fixer observed a timer-heavy auth-failure sample, and this patch bounds the only matching authentication delay so it cannot extend beyond the documented local maximum.
No prior Fixer patch is present in this workspace; `git status --short` is clean and no proposal patch file was found.
## Risks
The delay exists for authentication timing resistance, so the patch must not remove it or make invalid-user timing obviously sharper.
The evidence is indirect: the sampled process was sleeping with very low CPU, and raw investigation artifacts referenced by `evidence.json` are not available on disk here. The patch should be framed as a targeted mitigation for the observed timer sleep, not as proof of a reproduced runaway CPU bug.
## Validation
First try the project-level entrypoint from the workspace root:
```sh
./configure && make
```
Then run the narrow relevant regression target:
```sh
make tests LTESTS=password
```
For a bounded independent reproduction attempt, after building, run an auth-failure attempt under syscall tracing against a local test `sshd` and check for the failure-delay `nanosleep/clock_nanosleep` duration before and after the patch. If the local server setup is blocked by missing privileges or host-key/test setup, report the exact command and failure, then at minimum compile the touched object via `make auth2.o`.
## Patch Pass
Subject: auth2: cap scaled userauth failure delay
## Commit Message
Fixer observed `sshd-auth` sleeping in an authentication failure path: the trace shows a `clock_nanosleep` before encrypted failure-response writes. Bound the scaled userauth failure delay so the total time since the request started cannot exceed `MAX_FAIL_DELAY_SECONDS`.
The delay still preserves the existing timing-obfuscation behavior, but the “scale up” bucket is now capped before sleeping.
## Evidence Confidence
observed
## Issue Connection
Fixer observed this failure signal directly but I did not independently reproduce it: `sshd-auth: root [net]` was in `S (sleeping)`, with strace showing a 1.612s `clock_nanosleep` followed by writes, and perf/proc evidence classifying the sample as timer-heavy.
The matching code path is `auth2.c` user authentication failure handling. `ensure_minimum_time_since()` applies a per-user delay before `SSH2_MSG_USERAUTH_FAILURE`; if authentication work has already passed the requested delay, it doubles the target delay bucket. Before this patch, that doubled bucket was not capped, so the total failure handling time could exceed the function’s own `MAX_FAIL_DELAY_SECONDS`.
The patch clamps the scaled bucket to `MAX_FAIL_DELAY_SECONDS` and avoids a zero or negative sleep. The expected effect is that authentication failure timing remains padded, but `sshd-auth` cannot add an oversized sleep past the intended maximum while preparing a failure response.
I followed the saved plan. Local conventions checked: `README.md` and `regress/README.regress`; nearby code uses `monotime_double()`, `debug3_f()`, `nanosleep()`, `ssh_packet_write_wait()`, `atomicio()`, `xmalloc()`, and `freezero()`. No relevant local wrapper replaces this direct sleep path.
## Git Add Paths
auth2.c
## Validation
`./configure && make` failed before building: `configure: error: ./configure.ac newer than configure, run autoreconf`.
`autoreconf && ./configure && make` passed from the workspace root.
`make tests LTESTS=password` was attempted as the bounded independent reproduction/regression check, but it did not reach the auth failure path. It failed with `Unsupported option UsePAM`, `Missing privilege separation directory: /var/empty`, and `FATAL: sshd_proxy broken`.
`make auth2.o` passed as the focused compile check for the touched file.
`git diff --check` passed.
## Review Pass 1 (local metadata check)
RESULT: fix-needed
## Findings
1. Patch metadata drift: the workspace currently changes `auth2.c`, `regress/authorized_keys_root`, `regress/check-perm`, `regress/data`, `regress/ecdsa-sha2-nistp256`, `regress/ecdsa-sha2-nistp256.pub`, `regress/ecdsa-sha2-nistp384`, `regress/ecdsa-sha2-nistp384.pub`, `regress/ecdsa-sha2-nistp521`, `regress/ecdsa-sha2-nistp521.pub`, `regress/failed-regress.log`, `regress/failed-ssh.log`, `regress/failed-sshd.log`, `regress/host.ecdsa-sha2-nistp256`, `regress/host.ecdsa-sha2-nistp384`, `regress/host.ecdsa-sha2-nistp521`, `regress/host.sk-ecdsa-sha2-nistp256@openssh.com`, `regress/host.sk-ssh-ed25519@openssh.com`, `regress/host.ssh-ed25519`, `regress/host.ssh-rsa`, `regress/known_hosts`, `regress/log/20260514T084308.530290.ssh.202.log`, `regress/mkdtemp`, `regress/modpipe`, `regress/netcat`, `regress/regress.log`, `regress/rsa_ssh2_cr.prv`, `regress/rsa_ssh2_crnl.prv`, `regress/setuid-allowed`, `regress/sk-ecdsa-sha2-nistp256@openssh.com`, `regress/sk-ecdsa-sha2-nistp256@openssh.com.pub`, `regress/sk-ssh-ed25519@openssh.com`, `regress/sk-ssh-ed25519@openssh.com.pub`, `regress/ssh-ed25519`, `regress/ssh-ed25519.pub`, `regress/ssh-log-wrapper.sh`, `regress/ssh-rsa`, `regress/ssh-rsa.pub`, `regress/ssh.log`, `regress/ssh_config`, `regress/ssh_proxy`, `regress/sshd-log-wrapper.sh`, `regress/sshd.log`, `regress/sshd_config`, `regress/sshd_proxy`, `regress/t10.out.pub`, `regress/t12.out.pub`, `regress/t7.out.pub`, `regress/t9.out.pub`, `regress/timestamp`, but `## Git Add Paths` lists `auth2.c`. Update `## Git Add Paths` to match the real shipped file set exactly, and make sure `## Issue Connection` explains every functional file that remains in the patch.
2. Missing from `## Git Add Paths`: `regress/authorized_keys_root`, `regress/check-perm`, `regress/data`, `regress/ecdsa-sha2-nistp256`, `regress/ecdsa-sha2-nistp256.pub`, `regress/ecdsa-sha2-nistp384`, `regress/ecdsa-sha2-nistp384.pub`, `regress/ecdsa-sha2-nistp521`, `regress/ecdsa-sha2-nistp521.pub`, `regress/failed-regress.log`, `regress/failed-ssh.log`, `regress/failed-sshd.log`, `regress/host.ecdsa-sha2-nistp256`, `regress/host.ecdsa-sha2-nistp384`, `regress/host.ecdsa-sha2-nistp521`, `regress/host.sk-ecdsa-sha2-nistp256@openssh.com`, `regress/host.sk-ssh-ed25519@openssh.com`, `regress/host.ssh-ed25519`, `regress/host.ssh-rsa`, `regress/known_hosts`, `regress/log/20260514T084308.530290.ssh.202.log`, `regress/mkdtemp`, `regress/modpipe`, `regress/netcat`, `regress/regress.log`, `regress/rsa_ssh2_cr.prv`, `regress/rsa_ssh2_crnl.prv`, `regress/setuid-allowed`, `regress/sk-ecdsa-sha2-nistp256@openssh.com`, `regress/sk-ecdsa-sha2-nistp256@openssh.com.pub`, `regress/sk-ssh-ed25519@openssh.com`, `regress/sk-ssh-ed25519@openssh.com.pub`, `regress/ssh-ed25519`, `regress/ssh-ed25519.pub`, `regress/ssh-log-wrapper.sh`, `regress/ssh-rsa`, `regress/ssh-rsa.pub`, `regress/ssh.log`, `regress/ssh_config`, `regress/ssh_proxy`, `regress/sshd-log-wrapper.sh`, `regress/sshd.log`, `regress/sshd_config`, `regress/sshd_proxy`, `regress/t10.out.pub`, `regress/t12.out.pub`, `regress/t7.out.pub`, `regress/t9.out.pub`, `regress/timestamp`.
## Refinement Pass 1
Subject: auth2: cap scaled userauth failure delay
## Commit Message
Fixer observed `sshd-auth` sleeping in an authentication failure path: the trace shows a `clock_nanosleep` before encrypted failure-response writes. Bound the scaled userauth failure delay so the total time since the request started cannot exceed `MAX_FAIL_DELAY_SECONDS`.
The delay still preserves the existing timing-obfuscation behavior, but the scale-up bucket is now capped before sleeping.
## Evidence Confidence
observed
## Issue Connection
Fixer observed this failure signal directly but I did not independently reproduce it: `sshd-auth: root [net]` was in `S (sleeping)`, with strace showing a 1.612s `clock_nanosleep` followed by writes, and perf/proc evidence classifying the sample as timer-heavy.
The matching code path is `auth2.c` user authentication failure handling. `ensure_minimum_time_since()` applies a per-user delay before `SSH2_MSG_USERAUTH_FAILURE`; if authentication work has already passed the requested delay, it doubles the target delay bucket. Before this patch, that doubled bucket was not capped, so the total failure handling time could exceed the function’s own `MAX_FAIL_DELAY_SECONDS`.
The patch clamps the scaled bucket to `MAX_FAIL_DELAY_SECONDS` and avoids a zero or negative sleep. The expected effect is that authentication failure timing remains padded, but `sshd-auth` cannot add an oversized sleep past the intended maximum while preparing a failure response. I kept the short source comment explaining the cap invariant.
Review round 1 found generated regression byproducts in the workspace. I removed those unintended files; the final patch contains only `auth2.c`.
Local conventions checked: `README.md` and `regress/README.regress`; nearby code uses `monotime_double()`, `debug3_f()`, `nanosleep()`, `ssh_packet_write_wait()`, `atomicio()`, `xmalloc()`, and `freezero()`. No relevant local wrapper replaces this direct sleep path.
## Git Add Paths
auth2.c
## Validation
`./configure && make` passed from the workspace root.
`make check` was attempted, but this tree has no `check` target: `make: *** No rule to make target 'check'. Stop.`
`make regressclean && make tests LTESTS=password` was attempted as the bounded independent reproduction/regression check. File tests passed, but the auth test did not reach the failure path because `sshd_proxy` setup failed with `Unsupported option UsePAM`, `Missing privilege separation directory: /var/empty`, and `FATAL: sshd_proxy broken`.
`git diff --check` passed.
Final workspace status after cleanup shows only `auth2.c` modified.
## Review Pass 2
RESULT: okdiff --git a/auth2.c b/auth2.c
index 80f766e..787b410 100644
--- a/auth2.c
+++ b/auth2.c
@@ -250,15 +250,20 @@ ensure_minimum_time_since(double start, double seconds)
struct timespec ts;
double elapsed = monotime_double() - start, req = seconds, remain;
- if (elapsed > MAX_FAIL_DELAY_SECONDS) {
+ if (elapsed >= MAX_FAIL_DELAY_SECONDS) {
debug3_f("elapsed %0.3lfms exceeded the max delay "
"requested %0.3lfms)", elapsed*1000, req*1000);
return;
}
- /* if we've already passed the requested time, scale up */
- while ((remain = seconds - elapsed) < 0.0)
+ /* If we've passed the requested time, scale up within the cap. */
+ while (seconds < elapsed && seconds < MAX_FAIL_DELAY_SECONDS)
seconds *= 2;
+ if (seconds > MAX_FAIL_DELAY_SECONDS)
+ seconds = MAX_FAIL_DELAY_SECONDS;
+ remain = seconds - elapsed;
+ if (remain <= 0.0)
+ return;
ts.tv_sec = remain;
ts.tv_nsec = (remain - ts.tv_sec) * 1000000000;sshd-auth likely remains stuck in a timer churn loop. A diagnosis report and patch proposal were created locally.
## Plan Pass
You are planning a fixer patch before any edits happen.
Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. The original pre-edit snapshot is available at `./source` if you need to inspect it. For interpreter processes, plan from the script/application entrypoint evidence first and include the runtime only as a second investigation target unless the evidence proves a runtime bug.
Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.
Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `openssh` upstream patch, not just a Debian-local workaround. Inspect the relevant code, nearby callers, project contribution docs, and local helper/compat APIs, but do not edit files in this pass.
Return a short markdown plan with these exact sections:
## Problem
## Evidence Confidence
## Proposed Subject
## Patch Plan
## Risks
## Validation
Classify `## Evidence Confidence` as exactly one of `reproduced`, `observed`, or `inferred`. Use `inferred` only for a no-patch diagnosis/report plan unless you can name the extra evidence you will collect before editing; inferred source patches are blocked by Fixer because they are not pull-request-ready. For `observed` source-patch plans, plan to say in the final `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. The plan must explain how the proposed code change addresses the observed issue evidence, call out any prior Fixer patch that should be improved or replaced, reject awkward control flow such as avoidable `goto` if there is a cleaner bounded alternative, name any local helper APIs or maintainer conventions the patch should follow, and keep the intended maintainer-facing explanation clear enough that someone unfamiliar with the local complaint wording can still follow the fix. In `## Validation`, name the reproducible configure/build/test entrypoint you will try from the workspace root before any focused leaf compile or smoke check, and include one bounded independent reproduction attempt for the collected failure signal when it is safe and cheap. Do not plan to claim `reproduced` unless that reproduction command or test can actually show the failure.
## Patch Pass
You are working on a bounded fixer proposal.
Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Produce the smallest reasonable patch for the target repository, keep the change upstreamable, prefer the clearest control flow available, and do not keep avoidable `goto` when a simpler structure would read better. Before introducing new file, process, allocation, locking, networking, or platform APIs, inspect nearby code and project contribution docs for existing helpers or compatibility wrappers and use those local patterns unless you can explain why they do not fit. Validate from a reproducible workspace-root entrypoint before falling back to focused leaf commands; if a build or test cannot run, report the exact command, the exact blocker, and any narrower check you ran instead. During validation, also try one bounded independent reproduction of the collected failure signal when it is safe and cheap, such as a failing test, smoke command, perf/strace comparison, or before/after runtime check. Only use `reproduced` if that command or test actually reproduced the failure; otherwise keep `observed` and report the reproduction blocker. The final explanation must connect the observed issue evidence to the actual code change, not just paraphrase the diff. Write like a maintainer is going to read the patch mail cold: explain the bug in plain language, define subsystem-specific jargon the first time you need it, and make the causal story obvious. Explicitly classify evidence confidence as `reproduced`, `observed`, or `inferred`: `reproduced` means you reproduced the failure locally; `observed` means Fixer has direct crash/log/trace evidence but you did not independently reproduce it; `inferred` means the source patch is not pull-request-ready, so do not leave a source diff unless you first gather stronger observed/reproduced evidence; otherwise return a no-patch diagnosis/report. For any source-changing `observed` patch, say explicitly in `## Issue Connection` that the failure was observed by Fixer and not independently reproduced. If you introduce non-obvious state translation, index remapping, or backend split logic, add a short source comment that explains the invariant being preserved.
Start by explaining the likely root cause from the collected perf, strace, and /proc evidence. If you cannot land a safe patch, leave a diagnosis that is strong enough for an upstream bug report.
Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout.
Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `openssh` upstream patch, not just a Debian-local workaround.
Keep the change narrowly scoped and summarize validation clearly.
In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:
## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.
## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.
## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short explanatory comment.
## Git Add Paths
List the repo-relative paths that belong in the final patch, one per line. Use `None` only when you intentionally made no source changes. Include intentionally new files, and do not list generated build artifacts.
## Validation
List the checks you ran, or say clearly that you could not run them. Include the independent reproduction command/test and result when `## Evidence Confidence` is `reproduced`; if reproduction was attempted but blocked, name the exact blocker and keep confidence at `observed` or `inferred`.
Before editing, read the plan at `./plan-output.txt` and follow it unless the code proves part of it wrong. If you change course, say so explicitly in the final write-up instead of silently drifting from the plan.
## Review Pass 1 (local metadata check)
Local metadata consistency check
## Refinement Pass 1
You are refining a fixer patch after an explicit code review.
Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Read the latest author response at `./patch-output.txt`. Read the review report at `./review-1-output.txt`. This is refinement round 1. The original pre-edit snapshot is available at `./source` if you need to compare the current patch against it. Re-read the planning pass at `./plan-output.txt` before editing. The workspace currently changes these repo-relative paths: auth2.c, regress/authorized_keys_root, regress/check-perm, regress/data, regress/ecdsa-sha2-nistp256, regress/ecdsa-sha2-nistp256.pub, regress/ecdsa-sha2-nistp384, regress/ecdsa-sha2-nistp384.pub, regress/ecdsa-sha2-nistp521, regress/ecdsa-sha2-nistp521.pub, regress/failed-regress.log, regress/failed-ssh.log, regress/failed-sshd.log, regress/host.ecdsa-sha2-nistp256, regress/host.ecdsa-sha2-nistp384, regress/host.ecdsa-sha2-nistp521, regress/host.sk-ecdsa-sha2-nistp256@openssh.com, regress/host.sk-ssh-ed25519@openssh.com, regress/host.ssh-ed25519, regress/host.ssh-rsa, regress/known_hosts, regress/log/20260514T084308.530290.ssh.202.log, regress/mkdtemp, regress/modpipe, regress/netcat, regress/regress.log, regress/rsa_ssh2_cr.prv, regress/rsa_ssh2_crnl.prv, regress/setuid-allowed, regress/sk-ecdsa-sha2-nistp256@openssh.com, regress/sk-ecdsa-sha2-nistp256@openssh.com.pub, regress/sk-ssh-ed25519@openssh.com, regress/sk-ssh-ed25519@openssh.com.pub, regress/ssh-ed25519, regress/ssh-ed25519.pub, regress/ssh-log-wrapper.sh, regress/ssh-rsa, regress/ssh-rsa.pub, regress/ssh.log, regress/ssh_config, regress/ssh_proxy, regress/sshd-log-wrapper.sh, regress/sshd.log, regress/sshd_config, regress/sshd_proxy, regress/t10.out.pub, regress/t12.out.pub, regress/t7.out.pub, regress/t9.out.pub, regress/timestamp. Either keep that exact set synchronized with `## Git Add Paths` and `## Issue Connection`, or revert any unintended file before you answer.
Upstream-style expectation: before planning or editing, check for contribution/style docs (`CONTRIBUTING`, `HACKING`, `README-hacking`, `README.md`, `docs/`, `dev-docs/`) and scan the touched subsystem for local helpers. If the project has wrappers for file IO, path-relative IO, process spawning, memory allocation, logging, locking, or platform compatibility, prefer those wrappers over generic libc/std APIs. Do not invent a reproducer or user-visible failure that is not in the evidence bundle; if the evidence is profiler-only or indirect, describe it as a targeted mitigation or stop with a diagnosis instead of presenting a speculative patch as a confirmed bug fix. In the plan and final validation, name any such helper, convention, or evidence limit you found, or say that no relevant local helper was found. Treat this as a `openssh` upstream patch, not just a Debian-local workaround.
Validation expectation: try the project-level build/test entrypoint from the workspace root before reporting only a focused leaf compile. Detected candidate(s): `./configure && make`, `make` and, if available, `make check`. If the project-level command fails because dependencies or generated files are missing, include the exact command and failure reason in `## Validation`, then run the narrowest relevant compile/test that is still reproducible from a clean checkout. Address the review findings with the smallest reasonable follow-up changes. If the review identifies a runtime or correctness bug in the changed code, you must update the code itself before answering; a metadata-only response is not sufficient. Keep the patch upstream-friendly, use local project helpers and compat APIs when available, avoid awkward control flow when a simpler structure will do, keep the final response gittable, make the maintainer-facing explanation plain and direct, keep `## Evidence Confidence` honest, add short comments for any non-obvious translation or remapping logic, run relevant project-level build/tests from the workspace root before narrower checks when possible, try a bounded independent reproduction command/test if the review or plan shows one is safe, and summarize which review findings you addressed.
In every authoring pass, your final response must start with `Subject: <single-line git commit subject>` and then include these markdown sections exactly:
## Commit Message
A short upstream-friendly explanation of what changed and why. Write it in plain language that a maintainer can follow without local complaint context. If you use subsystem jargon, define it immediately.
## Evidence Confidence
Exactly one word: `reproduced`, `observed`, or `inferred`. Use `reproduced` only when you reproduced the failure locally with a command or test, and include that command/test in `## Validation`. Use `observed` when Fixer has direct crash/log/trace evidence but you did not independently reproduce it. If `## Git Add Paths` lists source files for an `observed` patch, `## Issue Connection` must explicitly say the failure was observed by Fixer and not independently reproduced. Use `inferred` for profiler/strace/indirect evidence; inferred responses may be no-patch diagnoses or reports, but inferred source patches are not pull-request-ready until stronger evidence is gathered.
## Issue Connection
Write this as maintainer-facing patch mail, not as local Fixer notes. Cover four things explicitly in readable sentences: the user-visible symptom or the exact collected signal, the code-level cause or the cautious inference from evidence, the specific change you made, and the expected effect. Do not invent a reproducer, command line, crash, or user-visible failure that is not present in the evidence bundle. If the evidence is direct-but-not-reproduced, say it was observed by Fixer and not independently reproduced. If the evidence is indirect and you did not gather stronger evidence, do not leave a source diff; write a no-patch diagnosis/report instead. Include an explicit effect sentence such as `The expected effect is ...`, `This should reduce ...`, or `This prevents ...` for source patches. If the logic is non-obvious in code, mention that you added a short ex
[truncated 4402 bytes]## Plan Pass
## Problem
Fixer observed `sshd-auth: root [net]` sleeping around an authentication failure path with a `clock_nanosleep` followed by encrypted writes. The most relevant source path is `auth2.c`: `input_userauth_request()` calls `ensure_minimum_time_since()` before `userauth_finish()` sends `SSH2_MSG_USERAUTH_FAILURE`. That helper can exponentially scale a tiny per-user failure delay into a much larger sleep when authentication work has already exceeded the requested delay.
## Evidence Confidence
observed
## Proposed Subject
`auth2: cap scaled userauth failure delay at MAX_FAIL_DELAY_SECONDS`
## Patch Plan
1. Improve `auth2.c:ensure_minimum_time_since()` rather than touching Debian packaging or runtime/kernel code.
2. Preserve the intended per-user minimum failure delay from `user_specific_delay()`, but make the exponential “next bucket” behavior bounded so the total time since `tstart` cannot exceed `MAX_FAIL_DELAY_SECONDS`.
3. Use a simple bounded loop/local calculation, avoiding awkward control flow such as an avoidable `goto`.
4. Keep OpenSSH style: `debug3_f()` for diagnostics, `monotime_double()` for elapsed time, existing `nanosleep()` usage, `fatal_f`/`fatal_fr` conventions where needed. No relevant project-specific wrapper was found for this direct sleep path; nearby IO uses `ssh_packet_write_wait()` and monitor/file IO uses `atomicio()`, but this code is not doing file IO.
5. Do not claim this is a confirmed CPU runaway fix. The maintainer-facing explanation should say Fixer observed a timer-heavy auth-failure sample, and this patch bounds the only matching authentication delay so it cannot extend beyond the documented local maximum.
No prior Fixer patch is present in this workspace; `git status --short` is clean and no proposal patch file was found.
## Risks
The delay exists for authentication timing resistance, so the patch must not remove it or make invalid-user timing obviously sharper.
The evidence is indirect: the sampled process was sleeping with very low CPU, and raw investigation artifacts referenced by `evidence.json` are not available on disk here. The patch should be framed as a targeted mitigation for the observed timer sleep, not as proof of a reproduced runaway CPU bug.
## Validation
First try the project-level entrypoint from the workspace root:
```sh
./configure && make
```
Then run the narrow relevant regression target:
```sh
make tests LTESTS=password
```
For a bounded independent reproduction attempt, after building, run an auth-failure attempt under syscall tracing against a local test `sshd` and check for the failure-delay `nanosleep/clock_nanosleep` duration before and after the patch. If the local server setup is blocked by missing privileges or host-key/test setup, report the exact command and failure, then at minimum compile the touched object via `make auth2.o`.
## Patch Pass
Subject: auth2: cap scaled userauth failure delay
## Commit Message
Fixer observed `sshd-auth` sleeping in an authentication failure path: the trace shows a `clock_nanosleep` before encrypted failure-response writes. Bound the scaled userauth failure delay so the total time since the request started cannot exceed `MAX_FAIL_DELAY_SECONDS`.
The delay still preserves the existing timing-obfuscation behavior, but the “scale up” bucket is now capped before sleeping.
## Evidence Confidence
observed
## Issue Connection
Fixer observed this failure signal directly but I did not independently reproduce it: `sshd-auth: root [net]` was in `S (sleeping)`, with strace showing a 1.612s `clock_nanosleep` followed by writes, and perf/proc evidence classifying the sample as timer-heavy.
The matching code path is `auth2.c` user authentication failure handling. `ensure_minimum_time_since()` applies a per-user delay before `SSH2_MSG_USERAUTH_FAILURE`; if authentication work has already passed the requested delay, it doubles the target delay bucket. Before this patch, that doubled bucket was not capped, so the total failure handling time could exceed the function’s own `MAX_FAIL_DELAY_SECONDS`.
The patch clamps the scaled bucket to `MAX_FAIL_DELAY_SECONDS` and avoids a zero or negative sleep. The expected effect is that authentication failure timing remains padded, but `sshd-auth` cannot add an oversized sleep past the intended maximum while preparing a failure response.
I followed the saved plan. Local conventions checked: `README.md` and `regress/README.regress`; nearby code uses `monotime_double()`, `debug3_f()`, `nanosleep()`, `ssh_packet_write_wait()`, `atomicio()`, `xmalloc()`, and `freezero()`. No relevant local wrapper replaces this direct sleep path.
## Git Add Paths
auth2.c
## Validation
`./configure && make` failed before building: `configure: error: ./configure.ac newer than configure, run autoreconf`.
`autoreconf && ./configure && make` passed from the workspace root.
`make tests LTESTS=password` was attempted as the bounded independent reproduction/regression check, but it did not reach the auth failure path. It failed with `Unsupported option UsePAM`, `Missing privilege separation directory: /var/empty`, and `FATAL: sshd_proxy broken`.
`make auth2.o` passed as the focused compile check for the touched file.
`git diff --check` passed.
## Review Pass 1 (local metadata check)
RESULT: fix-needed
## Findings
1. Patch metadata drift: the workspace currently changes `auth2.c`, `regress/authorized_keys_root`, `regress/check-perm`, `regress/data`, `regress/ecdsa-sha2-nistp256`, `regress/ecdsa-sha2-nistp256.pub`, `regress/ecdsa-sha2-nistp384`, `regress/ecdsa-sha2-nistp384.pub`, `regress/ecdsa-sha2-nistp521`, `regress/ecdsa-sha2-nistp521.pub`, `regress/failed-regress.log`, `regress/failed-ssh.log`, `regress/failed-sshd.log`, `regress/host.ecdsa-sha2-nistp256`, `regress/host.ecdsa-sha2-nistp384`, `regress/host.ecdsa-sha2-nistp521`, `regress/host.sk-ecdsa-sha2-nistp256@openssh.com`, `regress/host.sk-ssh-ed25519@openssh.com`, `regress/host.ssh-ed25519`, `regress/host.ssh-rsa`, `regress/known_hosts`, `regress/log/20260514T084308.530290.ssh.202.log`, `regress/mkdtemp`, `regress/modpipe`, `regress/netcat`, `regress/regress.log`, `regress/rsa_ssh2_cr.prv`, `regress/rsa_ssh2_crnl.prv`, `regress/setuid-allowed`, `regress/sk-ecdsa-sha2-nistp256@openssh.com`, `regress/sk-ecdsa-sha2-nistp256@openssh.com.pub`, `regress/sk-ssh-ed25519@openssh.com`, `regress/sk-ssh-ed25519@openssh.com.pub`, `regress/ssh-ed25519`, `regress/ssh-ed25519.pub`, `regress/ssh-log-wrapper.sh`, `regress/ssh-rsa`, `regress/ssh-rsa.pub`, `regress/ssh.log`, `regress/ssh_config`, `regress/ssh_proxy`, `regress/sshd-log-wrapper.sh`, `regress/sshd.log`, `regress/sshd_config`, `regress/sshd_proxy`, `regress/t10.out.pub`, `regress/t12.out.pub`, `regress/t7.out.pub`, `regress/t9.out.pub`, `regress/timestamp`, but `## Git Add Paths` lists `auth2.c`. Update `## Git Add Paths` to match the real shipped file set exactly, and make sure `## Issue Connection` explains every functional file that remains in the patch.
2. Missing from `## Git Add Paths`: `regress/authorized_keys_root`, `regress/check-perm`, `regress/data`, `regress/ecdsa-sha2-nistp256`, `regress/ecdsa-sha2-nistp256.pub`, `regress/ecdsa-sha2-nistp384`, `regress/ecdsa-sha2-nistp384.pub`, `regress/ecdsa-sha2-nistp521`, `regress/ecdsa-sha2-nistp521.pub`, `regress/failed-regress.log`, `regress/failed-ssh.log`, `regress/failed-sshd.log`, `regress/host.ecdsa-sha2-nistp256`, `regress/host.ecdsa-sha2-nistp384`, `regress/host.ecdsa-sha2-nistp521`, `regress/host.sk-ecdsa-sha2-nistp256@openssh.com`, `regress/host.sk-ssh-ed25519@openssh.com`, `regress/host.ssh-ed25519`, `regress/host.ssh-rsa`, `regress/known_hosts`, `regress/log/20260514T084308.530290.ssh.202.log`, `regress/mkdtemp`, `regress/modpipe`, `regress/netcat`, `regress/regress.log`, `regress/rsa_ssh2_cr.prv`, `regress/rsa_ssh2_crnl.prv`, `regress/setuid-allowed`, `regress/sk-ecdsa-sha2-nistp256@openssh.com`, `regress/sk-ecdsa-sha2-nistp256@openssh.com.pub`, `regress/sk-ssh-ed25519@openssh.com`, `regress/sk-ssh-ed25519@openssh.com.pub`, `regress/ssh-ed25519`, `regress/ssh-ed25519.pub`, `regress/ssh-log-wrapper.sh`, `regress/ssh-rsa`, `regress/ssh-rsa.pub`, `regress/ssh.log`, `regress/ssh_config`, `regress/ssh_proxy`, `regress/sshd-log-wrapper.sh`, `regress/sshd.log`, `regress/sshd_config`, `regress/sshd_proxy`, `regress/t10.out.pub`, `regress/t12.out.pub`, `regress/t7.out.pub`, `regress/t9.out.pub`, `regress/timestamp`.
## Refinement Pass 1
Subject: auth2: cap scaled userauth failure delay
## Commit Message
Fixer observed `sshd-auth` sleeping in an authentication failure path: the trace shows a `clock_nanosleep` before encrypted failure-response writes. Bound the scaled userauth failure delay so the total time since the request started cannot exceed `MAX_FAIL_DELAY_SECONDS`.
The delay still preserves the existing timing-obfuscation behavior, but the scale-up bucket is now capped before sleeping.
## Evidence Confidence
observed
## Issue Connection
Fixer observed this failure signal directly but I did not independently reproduce it: `sshd-auth: root [net]` was in `S (sleeping)`, with strace showing a 1.612s `clock_nanosleep` followed by writes, and perf/proc evidence classifying the sample as timer-heavy.
The matching code path is `auth2.c` user authentication failure handling. `ensure_minimum_time_since()` applies a per-user delay before `SSH2_MSG_USERAUTH_FAILURE`; if authentication work has already passed the requested delay, it doubles the target delay bucket. Before this patch, that doubled bucket was not capped, so the total failure handling time could exceed the function’s own `MAX_FAIL_DELAY_SECONDS`.
The patch clamps the scaled bucket to `MAX_FAIL_DELAY_SECONDS` and avoids a zero or negative sleep. The expected effect is that authentication failure timing remains padded, but `sshd-auth` cannot add an oversized sleep past the intended maximum while preparing a failure response. I kept the short source comment explaining the cap invariant.
Review round 1 found generated regression byproducts in the workspace. I removed those unintended files; the final patch contains only `auth2.c`.
Local conventions checked: `README.md` and `regress/README.regress`; nearby code uses `monotime_double()`, `debug3_f()`, `nanosleep()`, `ssh_packet_write_wait()`, `atomicio()`, `xmalloc()`, and `freezero()`. No relevant local wrapper replaces this direct sleep path.
## Git Add Paths
auth2.c
## Validation
`./configure && make` passed from the workspace root.
`make check` was attempted, but this tree has no `check` target: `make: *** No rule to make target 'check'. Stop.`
`make regressclean && make tests LTESTS=password` was attempted as the bounded independent reproduction/regression check. File tests passed, but the auth test did not reach the failure path because `sshd_proxy` setup failed with `Unsupported option UsePAM`, `Missing privilege separation directory: /var/empty`, and `FATAL: sshd_proxy broken`.
`git diff --check` passed.
Final workspace status after cleanup shows only `auth2.c` modified.
## Review Pass 2
RESULT: okdiff --git a/auth2.c b/auth2.c
index 80f766e..787b410 100644
--- a/auth2.c
+++ b/auth2.c
@@ -250,15 +250,20 @@ ensure_minimum_time_since(double start, double seconds)
struct timespec ts;
double elapsed = monotime_double() - start, req = seconds, remain;
- if (elapsed > MAX_FAIL_DELAY_SECONDS) {
+ if (elapsed >= MAX_FAIL_DELAY_SECONDS) {
debug3_f("elapsed %0.3lfms exceeded the max delay "
"requested %0.3lfms)", elapsed*1000, req*1000);
return;
}
- /* if we've already passed the requested time, scale up */
- while ((remain = seconds - elapsed) < 0.0)
+ /* If we've passed the requested time, scale up within the cap. */
+ while (seconds < elapsed && seconds < MAX_FAIL_DELAY_SECONDS)
seconds *= 2;
+ if (seconds > MAX_FAIL_DELAY_SECONDS)
+ seconds = MAX_FAIL_DELAY_SECONDS;
+ remain = seconds - elapsed;
+ if (remain <= 0.0)
+ return;
ts.tv_sec = remain;
ts.tv_nsec = (remain - ts.tv_sec) * 1000000000;