Hi Adam, On Mon, Nov 2, 2020 at 1:04 PM Adam Hill <sidepip...@gmail.com> wrote: > > Yep, I can confirm that the patch fixes the issue.
Thanks for testing, committed to trunk in https://svn.apache.org/r1883097 I'll propose a backport to 2.4.x ASAP. > Interestingly ( or maybe not ) I had a quick glance at apr_socket_close and > it seems to set a SO_LINGER timeout of 30 seconds, so I sort of expected the > problem still to happen but at half the transfer rate.... but that doesn't > seem to be the case. I don't see any (internal) use of (APR_)SO_LINGER in the APR library, one can call apr_socket_opt_set() to set the option on the socket but neither httpd nor APR seem to actually use it. > As I say, it was a very cursory look, so maybe it does more than that ( or > maybe the linger timeout is just time for the close() call to return but RST > isn't sent. ) That would be bad actually, SO_LINGER with a positive timeout (as opposed to zero timeout to reset the connection like mpm_event did) would/could cause close() to block, while abort_socket_nonblocking() in mpm_event must not block (at least from some callers). Unix systems don't block on close() unless SO_LINGER is used, removing the reset depends on this actually. > > Anyway, this does seem to be the fix, and you've got to hope that any type of > DoS attempting to take advantage of sockets in the various CLOSE_WAIT et al > states would be mitigated at kernel level. It certainly will do better than httpd which has no control on this anyway :) > > Thanks for looking at this Yann. Thanks for testing! Regards; Yann.
