The request processing is delayed by a timer. Since nginx updates internal time once at the start of each event loop iteration, this normally ensures constant time delay, adding a mitigation from time-based attacks. A notable exception to this is the case when there are no additional events before the timer expires. To ensure constant-time processing in this case as well, we trigger an additional event loop iteration by posting a dummy event for the next event loop iteration.
Now it looks similar to what it was before background subrequests were introduced in 9552758a786e.
When "aio" or "aio threads" is used while processing the response body of an in-memory background subrequest, the subrequest could be finalized with an aio operation still in progress. Upon aio completion either parent request is woken or the old r->write_event_handler is called again. The latter may result in request errors. In either case post_subrequest handler is never called with the full response body, which is typically expected when using in-memory subrequests. Currently in nginx background subrequests are created by the upstream module and the mirror module. The issue does not manifest itself with these subrequests because they are header-only. But it can manifest itself with third-party modules which create in-memory background subrequests.
We used to have default error_page overwrite for 495, 496, and 497, so
a configuration like
error_page 495 /error;
will result in error 400, much like without any error_page configured.
The 494 status code was introduced later (in 3848:de59ad6bf557, nginx 0.9.4),
and relevant changes to ngx_http_core_error_page() were missed, resulting
in inconsistent behaviour of "error_page 494" - with error_page configured
it results in 494 being returned instead of 400.
Reported by Frank Liu,
http://mailman.nginx.org/pipermail/nginx/2020-February/058957.html.
In "co64" atom chunk start offset is a 64-bit unsigned integer. When trimming the "mdat" atom, chunk offsets are casted to off_t values which are typically 64-bit signed integers. A specially crafted mp4 file with huge chunk offsets may lead to off_t overflow and result in negative trim boundaries. The consequences of the overflow are: - Incorrect Content-Length header value in the response. - Negative left boundary of the response file buffer holding the trimmed "mdat". This leads to pread()/sendfile() errors followed by closing the client connection. On rare systems where off_t is a 32-bit integer, this scenario is also feasible with the "stco" atom. The fix is to add checks which make sure data chunks referenced by each track are within the mp4 file boundaries. Additionally a few more checks are added to ensure mp4 file consistency and log errors.
During SSL handshake, the connection could be reused in the OCSP stapling callback, if configured, which subsequently leads to a segmentation fault.
Duplicate "Host" headers were allowed in nginx 0.7.0 (revision b9de93d804ea) as a workaround for some broken Motorola phones which used to generate requests with two "Host" headers[1]. It is believed that this workaround is no longer relevant. [1] http://mailman.nginx.org/pipermail/nginx-ru/2008-May/017845.html
The "identity" transfer coding has been removed in RFC 7230. It is believed that it is not used in real life, and at the same time it provides a potential attack vector.
We anyway do not support more than one transfer encoding, so accepting requests with multiple Transfer-Encoding headers doesn't make sense. Further, we do not handle multiple headers, and ignore anything but the first header. Reported by Filippo Valsorda.