When a request was retried to a new upstream after receiving 103 Early Hints from the previous one, the accumulated early_hints_length was not reset, causing valid early hints from the next upstream to be incorrectly rejected as "too big".
The issue described below was only reproducible prior to https://github.com/nginx/nginx/commit/7924a4ec6cb35291ea60a5f2a70ac0a034d94ff7 When parsing the `charset` parameter in the `Content-Type` header within `ngx_http_upstream_copy_content_type`, an input such as `charset="` resulted in an integer underflow. In this scenario, both `p` and `last` point to the position immediately following the opening quote. The logic to strip a trailing quote checked `*(last - 1)` without verifying that `last > p`. This caused `last` to be decremented to point to the opening quote itself, making `last < p`. The subsequent length calculation `r->headers_out.charset.len = last - p` resulted in -1, which wrapped to `SIZE_MAX` as `len` is a `size_t`. This invalid length was later passed to `ngx_cpymem` in `ngx_http_header_filter`, leading to an out-of-bounds memory access (detected as `negative-size-param` by AddressSanitizer). The fix ensures `last > p` before attempting to strip a trailing quote, correctly resulting in a zero-length charset for malformed input. The oss-fuzz payload that triggers this issue holds multiple 103 status lines, and it's a sequence of 2 of those Content-Type headers that trigger the ASAN report. Co-authored-by: CodeMender <codemender-patching@google.com> Fixes: https://issues.oss-fuzz.com/issues/486561029 Signed-off-by: David Korczynski <david@adalogics.com>
The second 103 response in a row was treated as the final response header.
With this parameter set, sessions are learned after receiving upstream headers.
While peer is draining, only sticky requests are served and the peer is never selected to process new requests. Co-authored-by: Ruslan Ermilov <ru@nginx.com>
Sticky sessions allow to route the same client to the same upstream server.
- upstream structures are extended to keep session-related information
- existing balancing modules are updated to provide an id of the selected
server (SID) in pc->sid, and to select the server, given it's SID.
- other balancing modules are allowed to set the pc->hint value to choose
the desired peer. The sticky module will not change the hint if it's
already set.
- the feature is enabled by default and can be disabled with the
"--without-http_upstream_sticky" switch of the configure script.
The following configuration can be used to enable sticky sessions for
supported balancing modules:
upstream u1 {
server 127.0.0.1:8080;
server 127.0.0.1:8081;
sticky cookie server_id expires=1h domain=.example.com path=/;
}
Co-authored-by: Ruslan Ermilov <ru@nginx.com>
Co-authored-by: Roman Arutyunyan <arut@nginx.com>
Co-authored-by: Maxim Dounin <mdounin@mdounin.ru>
Previously, when connecting to a backend, if the read event handler was called before the write event handler, and the received response triggered a next upstream condition, then ngx_http_upstream_reinit() was not called to clean up the old upstream context. This had multiple implications. For all proxy modules, since the last upstream response was not cleaned up, it was mixed with the next upstream response. This could result in ignoring the second response status code, duplicate response headers or reporting old upstream header errors. With ngx_http_grpc_module and ngx_http_proxy_v2_module, ctx->connection was left dangling since the object it referenced was allocated from the last upstream connection pool, which was deleted when freeing last upstream. This lead to use-after-free when trying to reuse this object for the next upstream.
When connecting to a backend, the connection write event is triggered first in most cases. However if a response arrives quickly enough, both read and write events can be triggered together within the same event loop iteration. In this case the read event handler is called first and the write event handler is called after it. SSL initialization for backend connections happens only in the write event handler since SSL handshake starts with sending Client Hello. Previously, if a backend sent a quick plain text response, it could be parsed by the read event handler prior to starting SSL handshake on the connection. The change adds protection against parsing such responses on SSL-enabled connections.
This commit is prepared for HTTP/2 and HTTP/3 support. The ALPN protocol is now set per-connection in ngx_http_upstream_ssl_init_connection(), allowing proper protocol negotiation for each individual upstream connection regardless of SSL context sharing.