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

Reply via email to