Hello,
I believe that I encountered segfault caused by this change:
details: http://freenginx.org/hg/nginx/rev/81082b5521dd
branches:
changeset: 9259:81082b5521dd
user: Maxim Dounin <mdou...@mdounin.ru>
date: Sat Apr 27 18:21:38 2024 +0300
description:
Request body: body is now cleared on errors.
Previously, after errors the request body was left in a potentially
inconsistent state, with r->headers_in.content_length_n which might be
larger than buffers actually stored in r->request_body->bufs (or not
set at all, in case of HTTP/2 and HTTP/3). This can cause issues if
the request body is subsequently used during error_page handling, such
as when proxying.
Fix is to clear r->request_body->bufs if this happens, and set
r->headers_in.content_length_n to 0, much like it happens when
ngx_http_discard_request_body() is called when returning 413 from
ngx_http_core_find_config_phase() for requests with Content-Length.
...
diff --git a/src/http/ngx_http_request_body.c b/src/http/ngx_http_request_body.c
--- a/src/http/ngx_http_request_body.c
+++ b/src/http/ngx_http_request_body.c
@@ -228,6 +228,11 @@ done:
}
if (rc >= NGX_HTTP_SPECIAL_RESPONSE) {
+
+ r->lingering_close = 1;
+ r->headers_in.content_length_n = 0;
+ r->request_body->bufs = NULL;
+
r->main->count--;
r->read_event_handler = ngx_http_block_reading;
}
The r->request_body may not be set here. It could happen at the top of
the ngx_http_read_client_request_body function, when either
ngx_http_test_expect or ngx_pcalloc fails and the goto done is executed
before setting r->request_body.
I encountered this with clients that sends Expect: 100-continue but
immediately closes the connection.
The fix should be straightforward, just to check for existence of the
r->request_body.
Sincerely
Jiří Setnička