Previously, if a subrequest was posted twice, it could be finalized in
both calls, excessively reducing r->main->count and potentially leading
to a use-after-free.
The fix is to avoid posting a request if it's already posted. Also,
as a hardening measure, r->write_event_handler is now reset to a no-op
handler during active subrequest finalization.
The problem manifests itself in ngx_http_ssi_filter_module during
unbuffered proxying. If a subrequest is created for an SSI include
statement while the main request has some data postponed by another
include, this subrequest becomes double-posted when the main request
data is flushed. The first post comes from ngx_http_subrequest() and
the second one comes from ngx_http_postpone_filter(). In case of a
quick subrequest finalization, the above mentioned problem happens.
Reported by P4P3R-HAK.
When ngx_http_regex_exec() reallocates r->captures array, it doesn't update
r->ncaptures value, if regex didn't match. So the next use of unnamed regex
capture triggers uninitialized read and potential buffer overrun.
This config demonstrates the issue:
map test $my_map {
volatile;
~mismatch(.*) 1; # reallocates r->captures in subrequests
default "";
}
server {
location ~(.*) { # sets r->ncaptures
slice 50;
# $1 will read from uninitialized memory in slice subrequests
proxy_set_header Test $my_map$1;
proxy_set_header Range $slice_range;
proxy_pass http://backend;
}
}
The issue was introduced by 746fba0d79.
If the script result turned out to be shorter than its predicted
length, the result string contained uninitialized bytes at the end.
The fix is to cut the result string by its actual size.
The following locations returned trailing garbage to the client with
URI "/1234abcd".
map $uri $foo {
~^/(?<bar>[0-9]).*$ $bar;
}
location ~(?<bar>[0-9]*)[a-z]*$ {
return 200 $1:$foo;
}
location ~(?<bar>[0-9]*)[a-z]*$ {
set $qux $1:$foo;
return 200 $qux;
}
Following the previous change, this change adds script overrun
protection to direct script evaluation in the proxy, fastcgi, scgi,
uwsgi, grpc proxy, index, and try_files modules.
This change is a modified version of a patch by Maxim Dounin. The
modifications include ngx_http_proxy_v2_module and hardened size checks.
Signed-off-by: Roman Arutyunyan <arut@nginx.com>
Origin: <https://freenginx.org/hg/nginx/rev/7e4d7feb4c77>
Similarly to generic script operations, access log script copy operations
now check if there is enough room in the buffer.
Signed-off-by: Roman Arutyunyan <arut@nginx.com>
Origin: <https://freenginx.org/hg/nginx/rev/ceff7ca7785a>
With this change, all script copy operations now check if there is
enough room in the buffer. To do so, the script engine now provides the
e->end pointer, which specifies expected buffer end, and each copy
operation is checked against it with the ngx_http_script_check_length()
function.
The e->end pointer is optional and only checked when set, thus
introducing no incompatible API changes. All standard functions were
updated to use it, notably ngx_http_complex_value(), ngx_http_script_run(),
ngx_http_script_regex_start_code(), ngx_http_script_complex_value_code().
Direct script evaluation in the proxy, fastcgi, scgi, uwsgi, grpc proxy,
index, and try_files modules will be updated by a separate patch.
In particular, this catches issues as observed when evaluating variables
with side effects, such as in the following configuration:
map $uri $map {
~(?<capture>.*) $capture;
}
set $capture "";
set $temp "$capture $map";
As well as when evaluating non-cacheable variables, where length of a
variable might change between length and copy codes, such as in the
following configuration:
map prefix:$capture $map_volatile {
volatile;
~(?<capture>.*) $capture;
}
set $capture "";
set $temp "$map_volatile";
Similar changes were made in the stream module.
Signed-off-by: Roman Arutyunyan <arut@nginx.com>
Origin: <https://freenginx.org/hg/nginx/rev/d172f506ab5f>
As per RFC 2817 Section 5.2:
Like any other pipelined HTTP/1.1 request, data to be tunneled may be
sent immediately after the blank line. The usual caveats also apply:
data may be discarded if the eventual response is negative, and the
connection may be reset with no response if more than one TCP segment
is outstanding.
As per RFC 9110, Section 9.3.6:
A CONNECT request message does not have content.
Also, as per Section 8.6:
A user agent SHOULD NOT send a Content-Length header field when the
request message does not contain content and the method semantics do
not anticipate such data.
Similarly to "listen ... sndbuf/rcvbuf", proxy_socket_sndbuf and
proxy_socket_rcvbuf can be used to set the SO_SNDBUF and SO_RCVBUF
socket options, respectively, on upstream connections. By default,
the values are left unchanged.
Closes: https://github.com/nginx/nginx/issues/1297
Similarly to "listen ... sndbuf/rcvbuf", proxy_socket_sndbuf and
proxy_socket_rcvbuf can be used to set the SO_SNDBUF and SO_RCVBUF
socket options, respectively, for upstream connections. By default,
the values are left unchanged.
Similar changes made in fastcgi, grpc, scgi, uwsgi, tunnel.
ngx_event_connect_peer() honors SO_RCVBUF via pc->rcvbuf but had
no equivalent for SO_SNDBUF. This adds pc->sndbuf and the matching
setsockopt() call, mirroring the existing SO_RCVBUF path.
Both setsockopt() calls are made non-fatal.
Existing callers leaving sndbuf at 0 retain prior behavior, since
setsockopt() is only invoked when the field is non-zero. These
fields are consumed by various proxying modules in follow-up commits.
Handling of pseudo-headers is refactored to be more in line with
HTTP/3 implementation, that is, a request line is now constructed
as soon as pseudo-headers are followed by regular fields. Here
this plugs a missing handling for absent mandatory or out-of-order
pseudo-headers.
Such requests are now rejected immediately as malformed.
Closes: https://github.com/nginx/nginx/issues/1526
Previously, using stale request objects resulted in accesses to already
freed memory, causing segmentation faults:
location /stale {
perl 'sub {
my $r = shift;
$prev->log_error(0, "next request arrived") if $prev;
$prev = $r;
$r->send_http_header;
return OK;
}';
}
Similarly, incorrectly blessed objects might cause segmentation faults,
such as in the following configuration:
location /bless {
perl 'sub {
my $v = 10;
my $r = bless \$v, "nginx";
$r->send_http_header;
return OK;
}';
}
With this change, active request object is recorded in the
ngx_http_perl_call_handler() function, and checked by
ngx_http_perl_set_request() to prevent use of unexpected request
objects.
Reported by Axel Mierczuk, Keith Hoodlet, 1Password’s Off-by-1 Labs.
Signed-off-by: Sergey Kandaurov <pluknet@nginx.com>
Origin: https://freenginx.org/hg/nginx/rev/86a2685756ae
Perl scalars might have a limited lifetime, and using them without
appropriate reference counting is incorrect. In particular, heap
use-after-free was observed in the following configuration (note the
"eval", which limits lifetime of the string being printed), which
demonstrates that the previously used SvREADONLY() optimizations are
incorrect:
location / {
perl 'sub {
my $r = shift;
$r->send_http_header;
eval q!$r->print("it works")!;
return OK;
}';
}
Similarly, errors were observed with handlers in $r->sleep() and
$r->has_request_body() when a handler comes from an eval, such as in
the following configuration:
location / {
perl 'sub {
my $r = shift;
$r->sleep(100, eval q!sub {
my $r = shift;
$r->send_http_header;
$r->print("it works");
return OK;
}!);
return OK;
}';
}
Accordingly, the SvREADONLY() optimization was removed in
ngx_http_perl_sv2str(), since it is expected to be used for small
strings, and using proper reference counting likely will be more costly
than just copying the string. In $r->print(), $r->sleep(), and
$r->has_request_body() proper reference counting was implemented, with
decrement operations being performed by pool cleanup handlers.
As a positive side effect, $r->print() can now avoid copying any single
scalar, not just read-only scalars.
Reported by Evan Hellman,
https://github.com/freenginx/nginx/issues/26
Signed-off-by: Sergey Kandaurov <pluknet@nginx.com>
Origin: https://freenginx.org/hg/nginx/rev/7a3dbb7905ad
Previously, calling $r->sleep() and $r->has_request_body() with an
invalid handler argument, such as a string, resulted in a segmentation
fault.
Signed-off-by: Sergey Kandaurov <pluknet@nginx.com>
Origin: https://freenginx.org/hg/nginx/rev/2442b26850b1
Previously, a revalidated cached response could fail on a cached
keepalive connection with "upstream sent frame for unknown stream"
error followed by "cache file contains invalid header".
This happened because after a 304 response, nginx parsed the cached
response while the upstream peer connection was still attached to the
request. The HTTP/2 proxy code treated cached frames as frames from
that live connection, and could assign a real stream id instead of
treating the cached response as having no real stream.
The fix is to treat cached response parsing as cache-only regardless
of the current upstream peer connection: set the stream id to 0 and
skip live upstream control-frame handling while r->cached is set.
Closes: https://github.com/nginx/nginx/issues/1318
HTTP/2 and gRPC upstream response header parsing used the HPACK string
length to allocate header name and value buffers. The length was not
checked against the configured upstream buffer size before allocation.
A malicious upstream could force nginx to allocate excessive
request-pool memory before the header was rejected.
Reject oversized HTTP/2 header name and value lengths before allocation.
Also keep a per-header-block limit based on the upstream buffer size, so
a header block cannot consume unbounded memory across fields.
The window size change was previously kept in a local variable while
processing SETTINGS parameters. If parsing was suspended after
SETTINGS_INITIAL_WINDOW_SIZE, the value was lost on resume and was
acknowledged without being applied.
Store the initial window size change in the HTTP/2 state until the
SETTINGS frame is fully processed.
SSL_ech_get1_status() allocates inner_sni and outer_sni and transfers
ownership to the caller. On the allocation-failure path the function
returned without freeing them, unlike ngx_ssl_get_ech_status() which
frees both on all paths.
Loading of external entities defined in the internal DTD subset,
that is, in the XML document itself, is now disabled by default, and
can be re-enabled with "xml_external_entities on;". This makes
processing of untrusted XML responses with the xslt module slightly
safer (though still not recommended unless you thoughtfully considered
risks).
To prevent loading we intercept entities defined in the internal
subset via the entityDecl callback, and remove system identifiers from
entities. This ensures that entities cannot be loaded directly, but
still allows using of public entities with appropriate system XML
catalog.
Additionally, since libxml2 before 2.14.0 (Mar 27 2025) accepts
in-document catalogs by default, these are explicitly disabled.
Signed-off-by: Vadim Zhestikov <v.zhestikov@f5.com>
Origin: https://freenginx.org/hg/nginx/rev/94dae9ab1018
Loading of external entities, including ones defined with the
xml_entities directive, happens while parsing the XML response, and
therefore loading over the network can block the entire worker process
for a long time. Loading of external DTD subset is disabled for the
very same reason since initial version of the module.
Further, loading over the network is anyway not available by default
since libxml2 2.13.0 (Jun 12 2024) and completely removed in libxml2
2.15.0 (Sep 15 2025).
As such, the XML_PARSE_NONET parsing option (available since libxml2
2.6.2 from 2003) is now used to prevent loading of external entities
over the network.
Signed-off-by: Vadim Zhestikov <v.zhestikov@f5.com>
Origin: https://freenginx.org/hg/nginx/rev/081c50f47347
The fix includes the socket option level (IPPROTO_IPV6) in the feature
test and the macro (NGX_HAVE_IPV6_DONTFRAG) in the
ngx_configure_listening_sockets() function.
Reported by Eric Fortis.
Pass Upgrade through for HTTP/1.x clients only: both for active
connection upgrades (101 Switching Protocols) and for advertising
available upgrades in other responses (RFC 9110 Section 7.8).
Strip it for HTTP/2+ clients where connection-specific headers
are forbidden (RFC 9113 Section 8.2.2, RFC 9114 Section 4.2).
This reverts commit 2d71bdcf8b.
This is actually unnecessary. Thanks to Valentin Bartenev for the
analysis
1. ngx_http_v2_handle_continuation() handles split HPACK integers at
frame boundaries
2. HPACK integers are max 4 bytes (NGX_HTTP_V2_INT_OCTETS)
3. The function is only called when length < 4 (i.e., 1-3 bytes remain)
4. The copy destination is offset by 9 bytes (frame header size)
Since 3 < 9, source and destination never overlap.
Complex value compilation scans strings for $1..$9 capture references.
Check that a byte after '$' is present before testing it, matching
ngx_str_t length semantics and avoiding reliance on NUL termination.
Apply the same check to both HTTP and stream implementations.
When processing CONTINUATION frames, ngx_http_v2_handle_continuation()
used ngx_memcpy() to shift header block fragment data past the frame
header. If the fragment is larger than the frame header (9 bytes),
the source and destination regions overlap, which is undefined
behavior for memcpy. The same function already uses ngx_memmove()
for another overlapping shift.
With prerequisites similar to 696a7f1b9, it was possible to gain 1-byte
overread on invalid UTF-8 sequences. The reason is ngx_utf8_decode()
stops advancing the pointer position on the first encountered invalid
byte. The fix is to adjust the advanced pointer up to the whole saved
sequence in this case. Note that this may result in different output
compared to complete invalid UTF-8 sequences, which we can disregard
at this point.
Reported by Han Yan of Xiaomi and p4p3r of CYBERONE.
Creating a control/encoder/decoder stream while another such stream
already exists, is not allowed. Also, closing such a stream results
in connection closure with NGX_HTTP_V3_ERR_CLOSED_CRITICAL_STREAM.
However, since stream creation and connection closure are asynchronous,
there could be a window where two control/encoder/decoder streams
could coexist within a single cycle iteration. This could result
in reusing parsing context, such as encoder insert buffer.
The change adds a mask for all standard client uni streams ever created.
This allows to check if a stream of this type was created before.
While here, mandatory stream validation now also uses this mask.
Previously, it was allocated from the encoder stream pool. This could
lead to use-after-free if the stream was closed and another encoder
stream was opened.
Reported by Trung Nguyen (@everping) of CyStack.
