mirror of https://github.com/wolfSSL/wolfssh.git
The worker drops back to APP_STATE_LISTEN when an agent connection ends, but never closes the socket. The next accept() overwrites agentFd, so every agent connection after the first leaks the previous descriptor. The forward path has the same gap on its connection-reset arm, where the socket is closed but fwdFd keeps the closed number. A rekey was treated as a read failure and ended the session. It cannot just be skipped either: wolfSSH_worker() reports WS_REKEYING in place of WS_CHAN_RXD while keying, and nothing raises the data report again, so ignoring it strands whatever arrived in that call and the peer waits on an answer that never comes. This is the hazard the library already calls out for WS_EXTDATA, which is exempted from the same override. - close agentFd and clear it on both the read-zero and the ECONNRESET/ECONNABORTED arms - clear fwdFd on the forward reset arm, matching the read-zero arm - clear agentCtx.appFd and fwdCtx.appFd wherever the worker closes the socket, so the stored copy cannot outlive the descriptor - drain the channel on WS_REKEYING as well as WS_CHAN_RXD, and take an empty read as "nothing buffered" rather than a failure on that path. wolfSSH_ChannelIdRead() has no isKeying gate and the window credit it owes is parked until the rekey completes |
||
|---|---|---|
| .. | ||
| client | ||
| echoserver | ||
| portfwd | ||
| scpclient | ||
| sftpclient | ||
| tpmcertserver | ||
| include.am | ||