> On 27 Nov 2023, at 06:50, Maxim Dounin <mdounin@mdounin.ru> wrote:
>
> # HG changeset patch
> # User Maxim Dounin <mdounin@mdounin.ru>
> # Date 1701049758 -10800
> # Mon Nov 27 04:49:18 2023 +0300
> # Node ID faf0b9defc76b8683af466f8a950c2c241382970
> # Parent a5e39e9d1f4c84dcbe6a2f9e079372a3d63aef0b
> Upstream: fixed usage of closed sockets with filter finalization.
>
> When filter finalization is triggered when working with an upstream server,
> and error_page redirects request processing to some simple handler,
> ngx_http_request_finalize() triggers request termination when the response
> is sent. In particular, via the upstream cleanup handler, nginx will close
> the upstream connection and the corresponding socket.
>
> Still, this can happen to be with ngx_event_pipe() on stack. While
> the code will set p->downstream_error due to NGX_ERROR returned from the
> output filter chain by filter finalization, otherwise the error will be
> ignored till control returns to ngx_http_upstream_process_request().
> And event pipe might try reading from the (already closed) socket, resulting
> in "readv() failed (9: Bad file descriptor) while reading upstream" errors
> (or even segfaults with SSL).
>
> Such errors were seen with the following configuration:
>
> location /t2 {
> proxy_pass http://127.0.0.1:8080/big;
>
> image_filter_buffer 10m;
> image_filter resize 150 100;
> error_page 415 = /empty;
> }
>
> location /empty {
> return 204;
> }
>
> location /big {
> # big enough static file
> }
>
> Fix is to set p->upstream_error in ngx_http_upstream_finalize_request(),
> so the existing checks in ngx_event_pipe_read_upstream() will prevent
> further reading from the closed upstream connection.
>
> Similarly, p->upstream_error is now checked when handling events at
> ngx_event_pipe() exit, as checking p->upstream->fd is not enough if
> keepalive upstream connections are being used and the connection was
> saved to cache during request termination.
>

Setting p->upstream_error in ngx_http_upstream_finalize_request()
may look suspicious, because it is used to be set on connection errors
such as upstream timeout or recv error, or, as a recently introduced
exception in the fastcgi module, - also when the FastCGI record ends
prematurely, before receiving all the expected content.
But technically I think this is quite correct, because we no longer
want to receive further data, and also (and you mention this in the
commit log) this repeats closing an upstream connection socket in
the same place in ngx_http_upstream_finalize_request().
So I think it should be fine.

> diff --git a/src/event/ngx_event_pipe.c b/src/event/ngx_event_pipe.c
> --- a/src/event/ngx_event_pipe.c
> +++ b/src/event/ngx_event_pipe.c
> @@ -57,7 +57,9 @@ ngx_event_pipe(ngx_event_pipe_t *p, ngx_
> do_write = 1;
> }
>
> - if (p->upstream->fd != (ngx_socket_t) -1) {
> + if (p->upstream->fd != (ngx_socket_t) -1
> + && !p->upstream_error)
> + {
> rev = p->upstream->read;
>
> flags = (rev->eof || rev->error) ? NGX_CLOSE_EVENT : 0;
> diff --git a/src/http/ngx_http_upstream.c b/src/http/ngx_http_upstream.c
> --- a/src/http/ngx_http_upstream.c
> +++ b/src/http/ngx_http_upstream.c
> @@ -4561,6 +4561,10 @@ ngx_http_upstream_finalize_request(ngx_h
>
> u->peer.connection = NULL;
>
> + if (u->pipe) {
> + u->pipe->upstream_error = 1;
> + }
> +
> if (u->pipe && u->pipe->temp_file) {
> ngx_log_debug1(NGX_LOG_DEBUG_HTTP, r->connection->log, 0,
> "http upstream temp fd: %d",

Looks good.

--
Sergey Kandaurov
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel