Public issue detail
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>.
Last seen: 2026-05-13 06:39 UTC. Public JSON: /v1/issues/019dfdca-f6fb-77c3-987d-954b3b228857
This diff is preserved for inspection, but a related source-family upstream review is the current handoff. Use the retained patch as evidence only; do not open a duplicate review from this artifact.
sshd-auth likely remains stuck in a timer churn loop. A diagnosis report and patch proposal were created locally.
auth2: bound failed-auth delay after slow authCommit message.
Failed user authentication applies a small per-user delay to reduce timing leaks. When authentication work already exceeded that delay, `ensure_minimum_time_since()` scaled the delay upward until it exceeded the elapsed time, then slept the difference. Slow monitor or authentication backend work could therefore turn a millisecond-scale delay into a much longer `nanosleep()`.
Keep a bounded per-user delay for slow failed authentications instead of scaling it to match the elapsed backend time. Fast failures still wait until the requested per-user delay has elapsed.
Problem. 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>.
How this patch connects to the issue.
Fixer observed `sshd-auth` sleeping with traces dominated by `read`, `read`, and `clock_nanosleep`; sampled backtraces included `clock_nanosleep()`/`nanosleep()`, and the strace excerpt showed sleeps of about 0.46s and 1.78s after monitor/socket reads. This failure was observed by Fixer and not independently reproduced.
The source-level connection is a cautious match from inspection: `auth2.c` computes a per-user failed-auth delay, and the old slow-auth path repeatedly doubled that delay until it exceeded elapsed authentication work before calling `nanosleep()`. I changed that path to keep one bounded per-user delay when elapsed time already exceeds the target, rather than scaling the delay up to the slow backend time. I also added a short comment because this timing tradeoff is non-obvious.
The expected effect is to reduce long post-authentication sleeps in `sshd-auth` while preserving a per-user delay for failed authentication attempts instead of returning immediately after slow backend work.
This refinement addresses the review findings by replacing the first pass’s early return with a bounded delay and by describing the `auth2.c` mapping as an inspection-based connection, not a locally reproduced root cause. I found only `README.md` among the requested style docs, no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/`. The patch uses existing OpenSSH conventions in this file: `monotime_double()`, `debug3_f()`, and portable `nanosleep()` support.
auth2.cThis retained diff belongs to an issue family already tracked upstream as https://github.com/openssh/openssh-portable/pull/663 (closed-unmerged; 6 related rows).
These blockers remain on the preserved local diff, but the related upstream review above is the current handoff.
diff --git a/auth2.c b/auth2.c
index 80f766e..5bb007e 100644
--- a/auth2.c
+++ b/auth2.c
@@ -256,9 +256,14 @@ ensure_minimum_time_since(double start, double seconds)
return;
}
- /* if we've already passed the requested time, scale up */
- while ((remain = seconds - elapsed) < 0.0)
- seconds *= 2;
+ if ((remain = seconds - elapsed) <= 0.0) {
+ /*
+ * Authentication work already exceeded the target delay.
+ * Keep a bounded per-user delay without scaling it up to
+ * match slow backends.
+ */
+ remain = seconds;
+ }
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.
0x00007f97dda9a7d2 in ?? () from target:<path>
0x00007f97ddae7c7a in clock_nanosleep () from target:<path>
0x00007f97ddaf35e3 in nanosleep () from target:<path>
0x00005651d8f442b6 in ?? ()
0x00005651d8f9a4a6 in ?? ()
0x00005651d8f9a59d in ?? ()
0x00005651d8f42b2c in ?? ()
0x00005651d8f311d5 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-06-13 12:23 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
Last seen: 2026-06-13 12:23 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: 100.00% of sampled CPU passed through unresolved offset, with repeated read x5, write x5, clock_nanosleep x2.
Why this looks related: same classification, same package, same source package, same subsystem, same target, same wait site
Last seen: 2026-06-12 00:24 UTC. Public page: /issues/019e6016-53b8-76e3-84e2-fdf4c48c1b40. Public JSON: /v1/issues/019e6016-53b8-76e3-84e2-fdf4c48c1b40
sshd-auth is stuck in a likely timer churn loop: 100.00% of sampled CPU passed through rep_movs_alternative, with repeated thread backtraces show 1 thread(s) around 0x00007f371dc9a7d2 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-06-13 12:19 UTC. Public page: /issues/019ebffd-fcdb-7190-8855-011dca04e59d. Public JSON: /v1/issues/019ebffd-fcdb-7190-8855-011dca04e59d
sshd-auth is stuck in a likely timer churn loop: 50.00% of sampled CPU passed through __mmdrop, with repeated thread backtraces show 1 thread(s) around 0x00007f022069a7d2 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-06-13 07:40 UTC. Public page: /issues/019ebeda-74f7-7d32-8db2-b15521aec662. Public JSON: /v1/issues/019ebeda-74f7-7d32-8db2-b15521aec662
sshd-auth is stuck in a likely timer churn loop: 36.29% of sampled CPU passed through __schedule, with repeated thread backtraces show 1 thread(s) around 0x00007fac7249a7d2 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-06-08 23:10 UTC. Public page: /issues/019ea8c5-24b9-7863-b730-83081994767c. Public JSON: /v1/issues/019ea8c5-24b9-7863-b730-83081994767c
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
You are reviewing a freshly generated fixer patch.
Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Review the first patch pass. The original pre-edit snapshot is available at `./source` for diffing. The workspace currently changes these repo-relative paths: auth2.c. Verify that `## Git Add Paths` matches this exact set and that `## Issue Connection` explains every shipped functional file.
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`. 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. The latest author response is at `./patch-output.txt`. Inspect the current code and changed paths like a strict code reviewer. Focus on correctness, regressions, maintainability, awkward control flow such as avoidable `goto`, missing validation, weak or non-gittable commit message text, and explanations that fail to connect the observed issue evidence to the code change. Also review the maintainer experience: the patch mail should be easy to accept upstream, the user-visible bug should be explained in plain language, subsystem-specific jargon should be defined when first used, and any non-obvious state translation or index remapping in code should have a short explanatory comment. Reject patches that omit `## Evidence Confidence`, use anything other than `reproduced`, `observed`, or `inferred`, or sound more certain than that evidence level allows. Reject patches that claim `reproduced` unless `## Validation` names the concrete reproduction command or test and its result. Reject patches that invent a reproducer, command line, crash, or user-visible failure not present in the evidence bundle; indirect profiler or strace evidence may justify a cautious mitigation, but the author must say it is indirect instead of presenting it as a confirmed upstream bug. Reject patches that introduce generic libc/std APIs when nearby code or project docs provide a local compat/helper API for the same job, unless the author explicitly justifies the exception. Reject validation that only reports a leaf object/syntax build when a project-level configure/build/test entrypoint exists and was not attempted; if a full build cannot run, the author must show the exact failed command and blocker.
Do not apply code changes in this pass.
Return a short markdown review report. The first non-empty line must be exactly one of:
RESULT: ok
RESULT: fix-needed
If you choose `RESULT: fix-needed`, add a `## Findings` section with concrete, actionable items.
## 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. 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`. 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 explana
[truncated 6718 bytes]## Plan Pass
## Problem
`sshd-auth` was observed sleeping in a failed authentication path after monitor/socket reads. The likely source is `auth2.c:ensure_minimum_time_since()`: when auth work already exceeds the small per-user failure delay, it doubles the requested delay until it is greater than elapsed time, then sleeps the remainder. This can turn a 5-9 ms mitigation into hundreds of ms or seconds of extra `nanosleep()`.
## Evidence Confidence
observed
## Proposed Subject
`auth2: avoid extending failed-auth delay after slow authentication work`
## Patch Plan
Update `ensure_minimum_time_since()` in `auth2.c` so it only sleeps when elapsed time is below the requested per-user minimum delay. If `elapsed >= seconds`, return after a `debug3_f()` message instead of scaling the target delay upward.
Keep the change small and upstream-style: no Debian-local workaround, no new control-flow `goto`, no new abstraction. Use existing OpenSSH conventions already present in this file: `monotime_double()`, `debug3_f()`, `fatal_f()`, `xmalloc()`, `freezero()`, and the portable `nanosleep()` provided through `openbsd-compat` when needed. I found `README.md` but no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/` guidance in this source snapshot.
No prior Fixer patch was present in the workspace or Debian patch stack for this issue; Debian patches touch `auth2.c` for SELinux/GSSAPI only.
## Risks
The delay exists to reduce authentication timing side channels. The patch should preserve the minimum delay for fast failures while avoiding additional delay when the backend has already taken longer than the target. The maintainer-facing explanation should be careful: this is a targeted mitigation for Fixer-observed `sshd-auth` sleep churn, not a claim that a standalone test reproduced the production report.
## Validation
First try the project-level entrypoint from the workspace root:
```sh
./configure && make
```
If that fails because dependencies or generated files are missing, record the exact failure and then run the narrowest reproducible build, likely:
```sh
make auth2.o sshd-auth
```
Also run a bounded independent smoke attempt for the collected signal: start a local test `sshd`/`sshd-auth` from the build tree with a temporary config, perform one intentionally failed auth attempt, and trace for `clock_nanosleep`/`nanosleep`. For an observed plan, the final `## Issue Connection` should say the failure was observed by Fixer and not independently reproduced unless this smoke command actually demonstrates the same long post-auth sleep.
## Patch Pass
Subject: auth2: avoid extending failed-auth delay after slow auth
## Commit Message
Failed user authentication applies a small per-user delay to reduce timing leaks. If authentication work had already taken longer than that delay, `ensure_minimum_time_since()` doubled the target delay until it exceeded the elapsed time, then slept the difference. This could turn a millisecond-scale minimum into a much longer `nanosleep()`.
Return when elapsed time already satisfies the requested delay. Fast failures still sleep up to the requested minimum; slow failures no longer add extra delay.
## Evidence Confidence
observed
## Issue Connection
Fixer observed `sshd-auth` in a sleeping state with trace evidence dominated by `read`, `read`, and `clock_nanosleep`; sampled backtraces included `clock_nanosleep()`/`nanosleep()`, and the strace excerpt showed sleeps of about 0.46s and 1.78s after monitor/socket reads. This failure was observed by Fixer and not independently reproduced.
The code-level cause is that `auth2.c`’s failed-auth delay helper treated “already past the requested delay” as a reason to scale the requested delay upward, rather than as evidence that the minimum delay had already been met. I changed `ensure_minimum_time_since()` to return when elapsed time is already greater than or equal to the requested per-user delay.
The expected effect is that failed authentication still preserves the intended minimum delay for fast failures, while avoiding extra `nanosleep()` churn after slow authentication backends or monitor work have already consumed that time.
I followed the saved plan. I found only `README.md` among the requested style docs, no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/`. The patch stays within existing OpenSSH conventions in this file: `monotime_double()`, `debug3_f()`, and the portable `nanosleep()` path.
## Git Add Paths
auth2.c
## Validation
`./configure && make` from the workspace root failed before build:
`configure: error: ./configure.ac newer than configure, run autoreconf`
To avoid modifying tracked generated files in the proposal workspace, I validated in a temporary copy:
`autoreconf && ./configure && make`
Result: passed. The build completed, including `sshd-auth`.
For the bounded smoke/trace attempt, I rebuilt the temporary copy with a writable privsep path:
`./configure --with-privsep-path=/tmp/openssh-privsep-90000.UVgiYb && make clean && make ssh sshd sshd-auth sshd-session`
Result: passed.
Independent reproduction attempt was blocked by the sandbox before authentication:
`strace ... ./sshd -D -e -f <temp config>` failed with `PTRACE_TRACEME: Operation not permitted` / `ptrace(PTRACE_SEIZE, ...): Operation not permitted`, and the local client failed with `socket: Operation not permitted`. Therefore I did not classify this as reproduced.
## Review Pass 1
RESULT: fix-needed
## Findings
- [auth2.c:259](./workspace/auth2.c:259): The patch removes the existing “scale up” behavior in a timing-attack mitigation without replacing it with a bounded equivalent. The original code deliberately rounded slow failed authentications up to the next per-user delay bucket, while this change returns immediately once backend/monitor work exceeds the 5-9 ms target. That may re-expose timing differences from PAM/monitor/user lookup paths. A safer patch needs to preserve the timing-mitigation invariant while bounding pathological sleeps, and the commit message should explain that tradeoff.
- The `## Issue Connection` is too certain about the source-level cause. The evidence directly shows `sshd-auth` sleeping in `clock_nanosleep()`/`nanosleep()` after monitor/socket reads, but the backtrace frames inside `sshd-auth` are unresolved. The write-up should describe the `auth2.c` mapping as a source-inspection match/cautious inference from the observed trace, not as a confirmed reproduced root cause.
The reported `## Git Add Paths` matches the actual changed path set (`auth2.c`), and validation did attempt the required workspace-root `./configure && make` before falling back.
## Refinement Pass 1
Subject: auth2: bound failed-auth delay after slow auth
## Commit Message
Failed user authentication applies a small per-user delay to reduce timing leaks. When authentication work already exceeded that delay, `ensure_minimum_time_since()` scaled the delay upward until it exceeded the elapsed time, then slept the difference. Slow monitor or authentication backend work could therefore turn a millisecond-scale delay into a much longer `nanosleep()`.
Keep a bounded per-user delay for slow failed authentications instead of scaling it to match the elapsed backend time. Fast failures still wait until the requested per-user delay has elapsed.
## Evidence Confidence
observed
## Issue Connection
Fixer observed `sshd-auth` sleeping with traces dominated by `read`, `read`, and `clock_nanosleep`; sampled backtraces included `clock_nanosleep()`/`nanosleep()`, and the strace excerpt showed sleeps of about 0.46s and 1.78s after monitor/socket reads. This failure was observed by Fixer and not independently reproduced.
The source-level connection is a cautious match from inspection: `auth2.c` computes a per-user failed-auth delay, and the old slow-auth path repeatedly doubled that delay until it exceeded elapsed authentication work before calling `nanosleep()`. I changed that path to keep one bounded per-user delay when elapsed time already exceeds the target, rather than scaling the delay up to the slow backend time. I also added a short comment because this timing tradeoff is non-obvious.
The expected effect is to reduce long post-authentication sleeps in `sshd-auth` while preserving a per-user delay for failed authentication attempts instead of returning immediately after slow backend work.
This refinement addresses the review findings by replacing the first pass’s early return with a bounded delay and by describing the `auth2.c` mapping as an inspection-based connection, not a locally reproduced root cause. I found only `README.md` among the requested style docs, no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/`. The patch uses existing OpenSSH conventions in this file: `monotime_double()`, `debug3_f()`, and portable `nanosleep()` support.
## Git Add Paths
auth2.c
## Validation
`./configure && make` from the workspace root failed before build:
`configure: error: ./configure.ac newer than configure, run autoreconf`
To avoid modifying tracked generated files in the proposal workspace, I validated in a temporary copy:
`autoreconf && ./configure --with-privsep-path=/tmp/openssh-privsep-90000-r1.o2UxDA && make`
Result: passed.
Bounded independent reproduction attempt:
A temporary `sshd` config using the built `sshd`, `sshd-auth`, and `sshd-session` passed `./sshd -t -f <temp config>`, but the runtime trace attempt was blocked before authentication. `strace ... ./sshd -D -e -f <temp config>` failed with `PTRACE_TRACEME: Operation not permitted` / `ptrace(PTRACE_SEIZE, ...): Operation not permitted`, and the local client failed with `socket: Operation not permitted`. Confidence remains `observed`, not `reproduced`.
## Review Pass 2
RESULT: ok
The refined patch only changes `auth2.c`, and `## Git Add Paths` matches that exact set.
The code now addresses the prior correctness concern: it preserves a bounded per-user failed-auth delay when authentication work already exceeded the target, instead of returning immediately or scaling the delay up to match slow backend time. The added comment explains the non-obvious timing tradeoff.
The latest `## Issue Connection` is appropriately cautious: it identifies the `auth2.c` path as an inspection-based match to Fixer’s observed `sshd-auth` sleep traces, explicitly says the issue was not independently reproduced, and explains the expected effect without inventing a reproducer.
Validation is acceptable: the workspace-root `./configure && make` was attempted and the exact blocker was reported, followed by a reproducible temporary-copy `autoreconf && ./configure --with-privsep-path=... && make` build. The bounded runtime trace attempt was also reported with exact sandbox blockers.diff --git a/auth2.c b/auth2.c
index 80f766e..5bb007e 100644
--- a/auth2.c
+++ b/auth2.c
@@ -256,9 +256,14 @@ ensure_minimum_time_since(double start, double seconds)
return;
}
- /* if we've already passed the requested time, scale up */
- while ((remain = seconds - elapsed) < 0.0)
- seconds *= 2;
+ if ((remain = seconds - elapsed) <= 0.0) {
+ /*
+ * Authentication work already exceeded the target delay.
+ * Keep a bounded per-user delay without scaling it up to
+ * match slow backends.
+ */
+ remain = seconds;
+ }
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
You are reviewing a freshly generated fixer patch.
Read the evidence bundle at `./evidence.json`. The prepared workspace is `./workspace` and it was acquired via `debian-source`. Review the first patch pass. The original pre-edit snapshot is available at `./source` for diffing. The workspace currently changes these repo-relative paths: auth2.c. Verify that `## Git Add Paths` matches this exact set and that `## Issue Connection` explains every shipped functional file.
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`. 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. The latest author response is at `./patch-output.txt`. Inspect the current code and changed paths like a strict code reviewer. Focus on correctness, regressions, maintainability, awkward control flow such as avoidable `goto`, missing validation, weak or non-gittable commit message text, and explanations that fail to connect the observed issue evidence to the code change. Also review the maintainer experience: the patch mail should be easy to accept upstream, the user-visible bug should be explained in plain language, subsystem-specific jargon should be defined when first used, and any non-obvious state translation or index remapping in code should have a short explanatory comment. Reject patches that omit `## Evidence Confidence`, use anything other than `reproduced`, `observed`, or `inferred`, or sound more certain than that evidence level allows. Reject patches that claim `reproduced` unless `## Validation` names the concrete reproduction command or test and its result. Reject patches that invent a reproducer, command line, crash, or user-visible failure not present in the evidence bundle; indirect profiler or strace evidence may justify a cautious mitigation, but the author must say it is indirect instead of presenting it as a confirmed upstream bug. Reject patches that introduce generic libc/std APIs when nearby code or project docs provide a local compat/helper API for the same job, unless the author explicitly justifies the exception. Reject validation that only reports a leaf object/syntax build when a project-level configure/build/test entrypoint exists and was not attempted; if a full build cannot run, the author must show the exact failed command and blocker.
Do not apply code changes in this pass.
Return a short markdown review report. The first non-empty line must be exactly one of:
RESULT: ok
RESULT: fix-needed
If you choose `RESULT: fix-needed`, add a `## Findings` section with concrete, actionable items.
## 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. 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`. 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 explana
[truncated 6718 bytes]## Plan Pass
## Problem
`sshd-auth` was observed sleeping in a failed authentication path after monitor/socket reads. The likely source is `auth2.c:ensure_minimum_time_since()`: when auth work already exceeds the small per-user failure delay, it doubles the requested delay until it is greater than elapsed time, then sleeps the remainder. This can turn a 5-9 ms mitigation into hundreds of ms or seconds of extra `nanosleep()`.
## Evidence Confidence
observed
## Proposed Subject
`auth2: avoid extending failed-auth delay after slow authentication work`
## Patch Plan
Update `ensure_minimum_time_since()` in `auth2.c` so it only sleeps when elapsed time is below the requested per-user minimum delay. If `elapsed >= seconds`, return after a `debug3_f()` message instead of scaling the target delay upward.
Keep the change small and upstream-style: no Debian-local workaround, no new control-flow `goto`, no new abstraction. Use existing OpenSSH conventions already present in this file: `monotime_double()`, `debug3_f()`, `fatal_f()`, `xmalloc()`, `freezero()`, and the portable `nanosleep()` provided through `openbsd-compat` when needed. I found `README.md` but no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/` guidance in this source snapshot.
No prior Fixer patch was present in the workspace or Debian patch stack for this issue; Debian patches touch `auth2.c` for SELinux/GSSAPI only.
## Risks
The delay exists to reduce authentication timing side channels. The patch should preserve the minimum delay for fast failures while avoiding additional delay when the backend has already taken longer than the target. The maintainer-facing explanation should be careful: this is a targeted mitigation for Fixer-observed `sshd-auth` sleep churn, not a claim that a standalone test reproduced the production report.
## Validation
First try the project-level entrypoint from the workspace root:
```sh
./configure && make
```
If that fails because dependencies or generated files are missing, record the exact failure and then run the narrowest reproducible build, likely:
```sh
make auth2.o sshd-auth
```
Also run a bounded independent smoke attempt for the collected signal: start a local test `sshd`/`sshd-auth` from the build tree with a temporary config, perform one intentionally failed auth attempt, and trace for `clock_nanosleep`/`nanosleep`. For an observed plan, the final `## Issue Connection` should say the failure was observed by Fixer and not independently reproduced unless this smoke command actually demonstrates the same long post-auth sleep.
## Patch Pass
Subject: auth2: avoid extending failed-auth delay after slow auth
## Commit Message
Failed user authentication applies a small per-user delay to reduce timing leaks. If authentication work had already taken longer than that delay, `ensure_minimum_time_since()` doubled the target delay until it exceeded the elapsed time, then slept the difference. This could turn a millisecond-scale minimum into a much longer `nanosleep()`.
Return when elapsed time already satisfies the requested delay. Fast failures still sleep up to the requested minimum; slow failures no longer add extra delay.
## Evidence Confidence
observed
## Issue Connection
Fixer observed `sshd-auth` in a sleeping state with trace evidence dominated by `read`, `read`, and `clock_nanosleep`; sampled backtraces included `clock_nanosleep()`/`nanosleep()`, and the strace excerpt showed sleeps of about 0.46s and 1.78s after monitor/socket reads. This failure was observed by Fixer and not independently reproduced.
The code-level cause is that `auth2.c`’s failed-auth delay helper treated “already past the requested delay” as a reason to scale the requested delay upward, rather than as evidence that the minimum delay had already been met. I changed `ensure_minimum_time_since()` to return when elapsed time is already greater than or equal to the requested per-user delay.
The expected effect is that failed authentication still preserves the intended minimum delay for fast failures, while avoiding extra `nanosleep()` churn after slow authentication backends or monitor work have already consumed that time.
I followed the saved plan. I found only `README.md` among the requested style docs, no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/`. The patch stays within existing OpenSSH conventions in this file: `monotime_double()`, `debug3_f()`, and the portable `nanosleep()` path.
## Git Add Paths
auth2.c
## Validation
`./configure && make` from the workspace root failed before build:
`configure: error: ./configure.ac newer than configure, run autoreconf`
To avoid modifying tracked generated files in the proposal workspace, I validated in a temporary copy:
`autoreconf && ./configure && make`
Result: passed. The build completed, including `sshd-auth`.
For the bounded smoke/trace attempt, I rebuilt the temporary copy with a writable privsep path:
`./configure --with-privsep-path=/tmp/openssh-privsep-90000.UVgiYb && make clean && make ssh sshd sshd-auth sshd-session`
Result: passed.
Independent reproduction attempt was blocked by the sandbox before authentication:
`strace ... ./sshd -D -e -f <temp config>` failed with `PTRACE_TRACEME: Operation not permitted` / `ptrace(PTRACE_SEIZE, ...): Operation not permitted`, and the local client failed with `socket: Operation not permitted`. Therefore I did not classify this as reproduced.
## Review Pass 1
RESULT: fix-needed
## Findings
- [auth2.c:259](./workspace/auth2.c:259): The patch removes the existing “scale up” behavior in a timing-attack mitigation without replacing it with a bounded equivalent. The original code deliberately rounded slow failed authentications up to the next per-user delay bucket, while this change returns immediately once backend/monitor work exceeds the 5-9 ms target. That may re-expose timing differences from PAM/monitor/user lookup paths. A safer patch needs to preserve the timing-mitigation invariant while bounding pathological sleeps, and the commit message should explain that tradeoff.
- The `## Issue Connection` is too certain about the source-level cause. The evidence directly shows `sshd-auth` sleeping in `clock_nanosleep()`/`nanosleep()` after monitor/socket reads, but the backtrace frames inside `sshd-auth` are unresolved. The write-up should describe the `auth2.c` mapping as a source-inspection match/cautious inference from the observed trace, not as a confirmed reproduced root cause.
The reported `## Git Add Paths` matches the actual changed path set (`auth2.c`), and validation did attempt the required workspace-root `./configure && make` before falling back.
## Refinement Pass 1
Subject: auth2: bound failed-auth delay after slow auth
## Commit Message
Failed user authentication applies a small per-user delay to reduce timing leaks. When authentication work already exceeded that delay, `ensure_minimum_time_since()` scaled the delay upward until it exceeded the elapsed time, then slept the difference. Slow monitor or authentication backend work could therefore turn a millisecond-scale delay into a much longer `nanosleep()`.
Keep a bounded per-user delay for slow failed authentications instead of scaling it to match the elapsed backend time. Fast failures still wait until the requested per-user delay has elapsed.
## Evidence Confidence
observed
## Issue Connection
Fixer observed `sshd-auth` sleeping with traces dominated by `read`, `read`, and `clock_nanosleep`; sampled backtraces included `clock_nanosleep()`/`nanosleep()`, and the strace excerpt showed sleeps of about 0.46s and 1.78s after monitor/socket reads. This failure was observed by Fixer and not independently reproduced.
The source-level connection is a cautious match from inspection: `auth2.c` computes a per-user failed-auth delay, and the old slow-auth path repeatedly doubled that delay until it exceeded elapsed authentication work before calling `nanosleep()`. I changed that path to keep one bounded per-user delay when elapsed time already exceeds the target, rather than scaling the delay up to the slow backend time. I also added a short comment because this timing tradeoff is non-obvious.
The expected effect is to reduce long post-authentication sleeps in `sshd-auth` while preserving a per-user delay for failed authentication attempts instead of returning immediately after slow backend work.
This refinement addresses the review findings by replacing the first pass’s early return with a bounded delay and by describing the `auth2.c` mapping as an inspection-based connection, not a locally reproduced root cause. I found only `README.md` among the requested style docs, no `CONTRIBUTING`, `HACKING`, `README-hacking`, `docs/`, or `dev-docs/`. The patch uses existing OpenSSH conventions in this file: `monotime_double()`, `debug3_f()`, and portable `nanosleep()` support.
## Git Add Paths
auth2.c
## Validation
`./configure && make` from the workspace root failed before build:
`configure: error: ./configure.ac newer than configure, run autoreconf`
To avoid modifying tracked generated files in the proposal workspace, I validated in a temporary copy:
`autoreconf && ./configure --with-privsep-path=/tmp/openssh-privsep-90000-r1.o2UxDA && make`
Result: passed.
Bounded independent reproduction attempt:
A temporary `sshd` config using the built `sshd`, `sshd-auth`, and `sshd-session` passed `./sshd -t -f <temp config>`, but the runtime trace attempt was blocked before authentication. `strace ... ./sshd -D -e -f <temp config>` failed with `PTRACE_TRACEME: Operation not permitted` / `ptrace(PTRACE_SEIZE, ...): Operation not permitted`, and the local client failed with `socket: Operation not permitted`. Confidence remains `observed`, not `reproduced`.
## Review Pass 2
RESULT: ok
The refined patch only changes `auth2.c`, and `## Git Add Paths` matches that exact set.
The code now addresses the prior correctness concern: it preserves a bounded per-user failed-auth delay when authentication work already exceeded the target, instead of returning immediately or scaling the delay up to match slow backend time. The added comment explains the non-obvious timing tradeoff.
The latest `## Issue Connection` is appropriately cautious: it identifies the `auth2.c` path as an inspection-based match to Fixer’s observed `sshd-auth` sleep traces, explicitly says the issue was not independently reproduced, and explains the expected effect without inventing a reproducer.
Validation is acceptable: the workspace-root `./configure && make` was attempted and the exact blocker was reported, followed by a reproducible temporary-copy `autoreconf && ./configure --with-privsep-path=... && make` build. The bounded runtime trace attempt was also reported with exact sandbox blockers.diff --git a/auth2.c b/auth2.c
index 80f766e..5bb007e 100644
--- a/auth2.c
+++ b/auth2.c
@@ -256,9 +256,14 @@ ensure_minimum_time_since(double start, double seconds)
return;
}
- /* if we've already passed the requested time, scale up */
- while ((remain = seconds - elapsed) < 0.0)
- seconds *= 2;
+ if ((remain = seconds - elapsed) <= 0.0) {
+ /*
+ * Authentication work already exceeded the target delay.
+ * Keep a bounded per-user delay without scaling it up to
+ * match slow backends.
+ */
+ remain = seconds;
+ }
ts.tv_sec = remain;
ts.tv_nsec = (remain - ts.tv_sec) * 1000000000;