<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git/src/http/modules, branch release-1.27.1</title>
<subtitle>nginx</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/'/>
<entry>
<title>Mp4: rejecting unordered chunks in stsc atom.</title>
<updated>2024-08-12T14:20:45+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2024-08-12T14:20:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=88955b1044ef38315b77ad1a509d63631a790a0f'/>
<id>88955b1044ef38315b77ad1a509d63631a790a0f</id>
<content type='text'>
Unordered chunks could result in trak-&gt;end_chunk smaller than trak-&gt;start_chunk
in ngx_http_mp4_crop_stsc_data().  Later in ngx_http_mp4_update_stco_atom()
this caused buffer overread while trying to calculate trak-&gt;end_offset.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Unordered chunks could result in trak-&gt;end_chunk smaller than trak-&gt;start_chunk
in ngx_http_mp4_crop_stsc_data().  Later in ngx_http_mp4_update_stco_atom()
this caused buffer overread while trying to calculate trak-&gt;end_offset.
</pre>
</div>
</content>
</entry>
<entry>
<title>Mp4: fixed buffer underread while updating stsz atom.</title>
<updated>2024-08-12T14:20:43+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2024-08-12T14:20:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=7362d01658b61184108c21278443910da68f93b4'/>
<id>7362d01658b61184108c21278443910da68f93b4</id>
<content type='text'>
While cropping an stsc atom in ngx_http_mp4_crop_stsc_data(), a 32-bit integer
overflow could happen, which could result in incorrect seeking and a very large
value stored in "samples".  This resulted in a large invalid value of
trak-&gt;end_chunk_samples.  This value is further used to calculate the value of
trak-&gt;end_chunk_samples_size in ngx_http_mp4_update_stsz_atom().  While doing
this, a large invalid value of trak-&gt;end_chunk_samples could result in reading
memory before stsz atom start.  This could potentially result in a segfault.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While cropping an stsc atom in ngx_http_mp4_crop_stsc_data(), a 32-bit integer
overflow could happen, which could result in incorrect seeking and a very large
value stored in "samples".  This resulted in a large invalid value of
trak-&gt;end_chunk_samples.  This value is further used to calculate the value of
trak-&gt;end_chunk_samples_size in ngx_http_mp4_update_stsz_atom().  While doing
this, a large invalid value of trak-&gt;end_chunk_samples could result in reading
memory before stsz atom start.  This could potentially result in a segfault.
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream: variables support in proxy_limit_rate and friends.</title>
<updated>2023-11-25T21:57:09+00:00</updated>
<author>
<name>J Carter</name>
<email>jordan.carter@outlook.com</email>
</author>
<published>2023-11-25T21:57:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=71ca978a352e025151a78bfcedc0d64814b062cb'/>
<id>71ca978a352e025151a78bfcedc0d64814b062cb</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Optimized chain link usage (ticket #2614).</title>
<updated>2024-05-23T15:15:38+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2024-05-23T15:15:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=ea8270c6142869367c5608bff92df9f5b3f32d37'/>
<id>ea8270c6142869367c5608bff92df9f5b3f32d37</id>
<content type='text'>
Previously chain links could sometimes be dropped instead of being reused,
which could result in increased memory consumption during long requests.

A similar chain link issue in ngx_http_gzip_filter_module was fixed in
da46bfc484ef (1.11.10).

Based on a patch by Sangmin Lee.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously chain links could sometimes be dropped instead of being reused,
which could result in increased memory consumption during long requests.

A similar chain link issue in ngx_http_gzip_filter_module was fixed in
da46bfc484ef (1.11.10).

Based on a patch by Sangmin Lee.
</pre>
</div>
</content>
</entry>
<entry>
<title>Rewrite: fixed "return" directive without response text.</title>
<updated>2024-02-26T20:00:28+00:00</updated>
<author>
<name>Piotr Sikora</name>
<email>piotr@aviatrix.com</email>
</author>
<published>2024-02-26T20:00:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=2f9e8431e696b27ffcd69e455a1ee006ca14f8e3'/>
<id>2f9e8431e696b27ffcd69e455a1ee006ca14f8e3</id>
<content type='text'>
Previously, the response text wasn't initialized and the rewrite module
was sending response body set to NULL.

Found with UndefinedBehaviorSanitizer (pointer-overflow).

Signed-off-by: Piotr Sikora &lt;piotr@aviatrix.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, the response text wasn't initialized and the rewrite module
was sending response body set to NULL.

Found with UndefinedBehaviorSanitizer (pointer-overflow).

Signed-off-by: Piotr Sikora &lt;piotr@aviatrix.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Fixed undefined behaviour with IPv4-mapped IPv6 addresses.</title>
<updated>2024-03-18T13:14:30+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2024-03-18T13:14:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=3d5a356abb4f06b0f103290bd31a4c146233956b'/>
<id>3d5a356abb4f06b0f103290bd31a4c146233956b</id>
<content type='text'>
Previously, it could result when left-shifting signed integer due to implicit
integer promotion, such that the most significant bit appeared on the sign bit.

In practice, though, this results in the same left value as with an explicit
cast, at least on known compilers, such as GCC and Clang.  The reason is that
in_addr_t, which is equivalent to uint32_t and same as "unsigned int" in ILP32
and LP64 data type models, has the same type width as the intermediate after
integer promotion, so there's no side effects such as sign-extension.  This
explains why adding an explicit cast does not change object files in practice.

Found with UndefinedBehaviorSanitizer (shift).

Based on a patch by Piotr Sikora.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, it could result when left-shifting signed integer due to implicit
integer promotion, such that the most significant bit appeared on the sign bit.

In practice, though, this results in the same left value as with an explicit
cast, at least on known compilers, such as GCC and Clang.  The reason is that
in_addr_t, which is equivalent to uint32_t and same as "unsigned int" in ILP32
and LP64 data type models, has the same type width as the intermediate after
integer promotion, so there's no side effects such as sign-extension.  This
explains why adding an explicit cast does not change object files in practice.

Found with UndefinedBehaviorSanitizer (shift).

Based on a patch by Piotr Sikora.
</pre>
</div>
</content>
</entry>
<entry>
<title>Geo: fixed uninitialized memory access.</title>
<updated>2024-03-14T14:37:20+00:00</updated>
<author>
<name>Piotr Sikora</name>
<email>piotr@aviatrix.com</email>
</author>
<published>2024-03-14T14:37:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=d3d64cacb3ce96477d354fe17d3b5c6e348f933a'/>
<id>d3d64cacb3ce96477d354fe17d3b5c6e348f933a</id>
<content type='text'>
While copying ngx_http_variable_value_t structures to geo binary base
in ngx_http_geo_copy_values(), and similarly in the stream module,
uninitialized parts of these structures are copied as well.  These
include the "escape" field and possible holes.  Calculating crc32 of
this data triggers uninitialized memory access.

Found with MemorySanitizer.

Signed-off-by: Piotr Sikora &lt;piotr@aviatrix.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While copying ngx_http_variable_value_t structures to geo binary base
in ngx_http_geo_copy_values(), and similarly in the stream module,
uninitialized parts of these structures are copied as well.  These
include the "escape" field and possible holes.  Calculating crc32 of
this data triggers uninitialized memory access.

Found with MemorySanitizer.

Signed-off-by: Piotr Sikora &lt;piotr@aviatrix.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Overhauled some diagnostic messages akin to 1b05b9bbcebf.</title>
<updated>2024-03-22T10:51:14+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2024-03-22T10:51:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=ae1948aa40c48a97f2e171acb84eb04bfcbe1307'/>
<id>ae1948aa40c48a97f2e171acb84eb04bfcbe1307</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream: fixed handling of Status headers without reason-phrase.</title>
<updated>2023-08-31T19:59:17+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2023-08-31T19:59:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=fa46a5719924a5a4c48c515a903e0c46a4d98bcf'/>
<id>fa46a5719924a5a4c48c515a903e0c46a4d98bcf</id>
<content type='text'>
Status header with an empty reason-phrase, such as "Status: 404 ", is
valid per CGI specification, but looses the trailing space during parsing.
Currently, this results in "HTTP/1.1 404" HTTP status line in the response,
which violates HTTP specification due to missing trailing space.

With this change, only the status code is used from such short Status
header lines, so nginx will generate status line itself, with the space
and appropriate reason phrase if available.

Reported at:
https://mailman.nginx.org/pipermail/nginx/2023-August/EX7G4JUUHJWJE5UOAZMO5UD6OJILCYGX.html
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Status header with an empty reason-phrase, such as "Status: 404 ", is
valid per CGI specification, but looses the trailing space during parsing.
Currently, this results in "HTTP/1.1 404" HTTP status line in the response,
which violates HTTP specification due to missing trailing space.

With this change, only the status code is used from such short Status
header lines, so nginx will generate status line itself, with the space
and appropriate reason phrase if available.

Reported at:
https://mailman.nginx.org/pipermail/nginx/2023-August/EX7G4JUUHJWJE5UOAZMO5UD6OJILCYGX.html
</pre>
</div>
</content>
</entry>
<entry>
<title>SSL: removed the "ssl" directive.</title>
<updated>2023-06-08T10:49:27+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2023-06-08T10:49:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=d32f66f1e8dc81a0edbadbacf74191684a653d09'/>
<id>d32f66f1e8dc81a0edbadbacf74191684a653d09</id>
<content type='text'>
It has been deprecated since 7270:46c0c7ef4913 (1.15.0) in favour of
the "ssl" parameter of the "listen" directive, which has been available
since 2224:109849282793 (0.7.14).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It has been deprecated since 7270:46c0c7ef4913 (1.15.0) in favour of
the "ssl" parameter of the "listen" directive, which has been available
since 2224:109849282793 (0.7.14).
</pre>
</div>
</content>
</entry>
</feed>
