[Bug 4029] New: 10.6: ChannelTimeout busy-loops for up to 1s before each channel close

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=4029

            Bug ID: 4029
           Summary: 10.6: ChannelTimeout busy-loops for up to 1s before
                    each channel close
           Product: Portable OpenSSH
           Version: 10.6p1
          Hardware: amd64
                OS: Mac OS X
            Status: NEW
          Severity: minor
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: kmehltretter at gmail.com

Created attachment 3998
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3998&action=edit
diff: call the double deadline helpers in channel_handler()

Since the floating point conversion of the channel timeouts (channels.c
r1.470, misc.c r1.220, in 10.6) channel_handler() passes the double
expiry from channel_get_expiry(), and c->notbefore, to
ptimeout_deadline_monotime(), whose time_t parameter floors them. The
expiry has a fractional part, so the poll deadline falls up to a second
short of it, and until the real expiry ppoll() returns at once and the
loop spins. Every channel that ChannelTimeout closes costs up to a
second of CPU, and a sub-second timeout spins for its whole duration.
Unchanged in master 4079f38c5 and OpenBSD -current (2026-10-09).

Reproduce:

    /usr/bin/time ssh -o ChannelTimeout=session=2 host 'sleep 8'

CPU time (user+sys) per run, 20 runs each:

                            unpatched         patched
  ssh                       0.01 to 0.97 s    0.00 to 0.06 s
  sshd processes            0.13 to 1.04 s    0.02 to 0.05 s

The unpatched value is the fractional part of the expiry and wraps
around from run to run. Channels with staggered expiries add up: one
multiplexed connection that opened 32 idle sessions 0.25 s apart kept
the unpatched sshd-session at 7.2 s of CPU over an 11 s window, 0.08 s
patched, so an authenticated client can keep its server process busy
without running anything. A timeout of 2^63 s or more makes the
conversion undefined and the spin permanent (x86-64).

Fix attached, written assisted by an LLM and tested by hand: call the
ptimeout_deadline_*_double() helpers that the conversion added but
never used, and clamp in ptimeout_deadline_sec_double() by comparing as
a double. regress channel-timeout and connection-timeout pass.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.