<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git/src/http, branch release-1.28.3</title>
<subtitle>nginx</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/'/>
<entry>
<title>Dav: destination length validation for COPY and MOVE.</title>
<updated>2026-03-24T18:33:23+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2026-03-16T16:13:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=a1d18284e0a173c4ef2b28425535d0f640ae0a82'/>
<id>a1d18284e0a173c4ef2b28425535d0f640ae0a82</id>
<content type='text'>
Previously, when alias was used in a location with Dav COPY or MOVE
enabled, and the destination URI was shorter than the alias, integer
underflow could happen in ngx_http_map_uri_to_path(), which could
result in heap buffer overwrite, followed by a possible segfault.
With some implementations of memcpy(), the segfault could be avoided
and the overwrite could result in a change of the source or destination
file names to be outside of the location root.

Reported by Calif.io in collaboration with Claude and Anthropic Research.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, when alias was used in a location with Dav COPY or MOVE
enabled, and the destination URI was shorter than the alias, integer
underflow could happen in ngx_http_map_uri_to_path(), which could
result in heap buffer overwrite, followed by a possible segfault.
With some implementations of memcpy(), the segfault could be avoided
and the overwrite could result in a change of the source or destination
file names to be outside of the location root.

Reported by Calif.io in collaboration with Claude and Anthropic Research.
</pre>
</div>
</content>
</entry>
<entry>
<title>Mp4: fixed possible integer overflow on 32-bit platforms.</title>
<updated>2026-03-24T18:33:23+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2026-03-02T17:12:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=b23ac73b00313d159a99636c21ef71b828781018'/>
<id>b23ac73b00313d159a99636c21ef71b828781018</id>
<content type='text'>
Previously, a 32-bit overflow could happen while validating atom entries
count.  This allowed processing of an invalid atom with entrires beyond
its boundaries with reads and writes outside of the allocated mp4 buffer.

Reported by Prabhav Srinath (sprabhav7).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, a 32-bit overflow could happen while validating atom entries
count.  This allowed processing of an invalid atom with entrires beyond
its boundaries with reads and writes outside of the allocated mp4 buffer.

Reported by Prabhav Srinath (sprabhav7).
</pre>
</div>
</content>
</entry>
<entry>
<title>Mp4: avoid zero size buffers in output.</title>
<updated>2026-03-24T18:33:23+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2026-02-21T08:04:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=a172c880cb51f882a5dc999437e8b3a4f87630cc'/>
<id>a172c880cb51f882a5dc999437e8b3a4f87630cc</id>
<content type='text'>
Previously, data validation checks did not cover the cases when the output
contained empty buffers.  Such buffers are considered illegal and produce
"zero size buf in output" alerts.  The change rejects the mp4 files which
produce such alerts.

Also, the change fixes possible buffer overread and overwrite that could
happen while processing empty stco and co64 atoms, as reported by
Pavel Kohout (Aisle Research) and Tim Becker.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, data validation checks did not cover the cases when the output
contained empty buffers.  Such buffers are considered illegal and produce
"zero size buf in output" alerts.  The change rejects the mp4 files which
produce such alerts.

Also, the change fixes possible buffer overread and overwrite that could
happen while processing empty stco and co64 atoms, as reported by
Pavel Kohout (Aisle Research) and Tim Becker.
</pre>
</div>
</content>
</entry>
<entry>
<title>Mp4: validate sync sample values in stss atom.</title>
<updated>2026-03-24T18:33:23+00:00</updated>
<author>
<name>CodeByMoriarty</name>
<email>czyrabriones4@gmail.com</email>
</author>
<published>2026-02-23T00:45:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=4f0df130ba72982d34984f38d5007898765716b8'/>
<id>4f0df130ba72982d34984f38d5007898765716b8</id>
<content type='text'>
Per ISO 14496-12 Section 8.6.2, sync sample numbers must be 1-based.
A zero-valued stss entry caused ngx_http_mp4_seek_key_frame() to
return a key_prefix exceeding the samples consumed in the forward
stts pass, which led the backward loop in ngx_http_mp4_crop_stts_data()
to walk past the beginning of the stts data buffer.

The fix validates each stss entry in ngx_http_mp4_seek_key_frame()
and returns an error if a zero sync sample is encountered.  The
function signature is changed to return ngx_int_t so it can signal
errors to the caller.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Per ISO 14496-12 Section 8.6.2, sync sample numbers must be 1-based.
A zero-valued stss entry caused ngx_http_mp4_seek_key_frame() to
return a key_prefix exceeding the samples consumed in the forward
stts pass, which led the backward loop in ngx_http_mp4_crop_stts_data()
to walk past the beginning of the stts data buffer.

The fix validates each stss entry in ngx_http_mp4_seek_key_frame()
and returns an error if a zero sync sample is encountered.  The
function signature is changed to return ngx_int_t so it can signal
errors to the caller.
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream: reinit upstream after reading bad response.</title>
<updated>2026-02-04T17:22:23+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2026-01-28T16:38:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=6df8054cb21b4e5e857b4489e623a79575c2ab8e'/>
<id>6df8054cb21b4e5e857b4489e623a79575c2ab8e</id>
<content type='text'>
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-&gt;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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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-&gt;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.
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream: detect premature plain text response from SSL backend.</title>
<updated>2026-02-04T17:22:23+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2026-01-29T09:27:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=784fa05025cb8cd0c770f99bc79d2794b9f85b6e'/>
<id>784fa05025cb8cd0c770f99bc79d2794b9f85b6e</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>Proxy: fixed segfault in URI change.</title>
<updated>2025-12-23T18:40:33+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2025-11-24T11:57:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=eec047c936347bb1ebb6266a4c83f31fa9c78e24'/>
<id>eec047c936347bb1ebb6266a4c83f31fa9c78e24</id>
<content type='text'>
If request URI was shorter than location prefix, as after replacement
with try_files, location length was used to copy the remaining URI part
leading to buffer overread.

The fix is to replace full request URI in this case.  In the following
configuration, request "/123" is changed to "/" when sent to backend.

    location /1234 {
        try_files /123 =404;
        proxy_pass http://127.0.0.1:8080/;
    }

Closes #983 on GitHub.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If request URI was shorter than location prefix, as after replacement
with try_files, location length was used to copy the remaining URI part
leading to buffer overread.

The fix is to replace full request URI in this case.  In the following
configuration, request "/123" is changed to "/" when sent to backend.

    location /1234 {
        try_files /123 =404;
        proxy_pass http://127.0.0.1:8080/;
    }

Closes #983 on GitHub.
</pre>
</div>
</content>
</entry>
<entry>
<title>HTTP/2: extended guard for NULL buffer and zero length.</title>
<updated>2025-12-23T18:40:33+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2025-11-14T14:14:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=2b502468588835e479fcd76a2cc0d00394f2c32c'/>
<id>2b502468588835e479fcd76a2cc0d00394f2c32c</id>
<content type='text'>
In addition to moving memcpy() under the length condition in 15bf6d8cc,
which addressed a reported UB due to string function conventions, this
is repeated for advancing an input buffer, to make the resulting code
more clean and readable.

Additionally, although considered harmless for both string functions and
additive operators, as previously discussed in GitHub PR 866, this fixes
the main source of annoying sanitizer reports in the module.

Prodded by UndefinedBehaviorSanitizer (pointer-overflow).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In addition to moving memcpy() under the length condition in 15bf6d8cc,
which addressed a reported UB due to string function conventions, this
is repeated for advancing an input buffer, to make the resulting code
more clean and readable.

Additionally, although considered harmless for both string functions and
additive operators, as previously discussed in GitHub PR 866, this fixes
the main source of annoying sanitizer reports in the module.

Prodded by UndefinedBehaviorSanitizer (pointer-overflow).
</pre>
</div>
</content>
</entry>
<entry>
<title>OCSP: fixed invalid type for the 'ssl_ocsp' directive.</title>
<updated>2025-12-23T18:40:33+00:00</updated>
<author>
<name>Roman Semenov</name>
<email>r.semenov@f5.com</email>
</author>
<published>2025-10-22T18:24:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=366b5c65ad4b520525865f19bf74e4ee69ca15df'/>
<id>366b5c65ad4b520525865f19bf74e4ee69ca15df</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream: overflow detection in Cache-Control delta-seconds.</title>
<updated>2025-12-23T18:40:33+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2025-09-10T14:39:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=40aff4f241422084b57c27e38f700bc4f4503f6a'/>
<id>40aff4f241422084b57c27e38f700bc4f4503f6a</id>
<content type='text'>
Overflowing calculations are now aligned to the greatest positive integer
as specified in RFC 9111, Section 1.2.2.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Overflowing calculations are now aligned to the greatest positive integer
as specified in RFC 9111, Section 1.2.2.
</pre>
</div>
</content>
</entry>
</feed>
