<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git/src/core/ngx_string.c, branch release-1.29.2</title>
<subtitle>nginx</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/'/>
<entry>
<title>Mail: xtext encoding (RFC 3461) in XCLIENT LOGIN.</title>
<updated>2025-09-26T13:04:20+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2025-09-11T14:23:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=6f81314a070201afc4e25b975b1f915698cff634'/>
<id>6f81314a070201afc4e25b975b1f915698cff634</id>
<content type='text'>
The XCLIENT command uses xtext encoding for attribute values,
as specified in https://www.postfix.org/XCLIENT_README.html.

Reported by Igor Morgenstern of Aisle Research.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The XCLIENT command uses xtext encoding for attribute values,
as specified in https://www.postfix.org/XCLIENT_README.html.

Reported by Igor Morgenstern of Aisle Research.
</pre>
</div>
</content>
</entry>
<entry>
<title>Core: stricter UTF-8 handling in ngx_utf8_decode().</title>
<updated>2023-02-22T23:09:50+00:00</updated>
<author>
<name>Yugo Horie</name>
<email>u5.horie@gmail.com</email>
</author>
<published>2023-02-22T23:09:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=2c5fccd4693c0a68e1c72d65e016ba83e861120e'/>
<id>2c5fccd4693c0a68e1c72d65e016ba83e861120e</id>
<content type='text'>
An UTF-8 octet sequence cannot start with a 11111xxx byte (above 0xf8),
see https://datatracker.ietf.org/doc/html/rfc3629#section-3.  Previously,
such bytes were accepted by ngx_utf8_decode() and misinterpreted as 11110xxx
bytes (as in a 4-byte sequence).  While unlikely, this can potentially cause
issues.

Fix is to explicitly reject such bytes in ngx_utf8_decode().
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
An UTF-8 octet sequence cannot start with a 11111xxx byte (above 0xf8),
see https://datatracker.ietf.org/doc/html/rfc3629#section-3.  Previously,
such bytes were accepted by ngx_utf8_decode() and misinterpreted as 11110xxx
bytes (as in a 4-byte sequence).  While unlikely, this can potentially cause
issues.

Fix is to explicitly reject such bytes in ngx_utf8_decode().
</pre>
</div>
</content>
</entry>
<entry>
<title>Core: escaping of chars not allowed in URIs per RFC 3986.</title>
<updated>2021-06-28T15:01:11+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2021-06-28T15:01:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=fee09fc49d510de0078f9bc7fc18dc179cceb62b'/>
<id>fee09fc49d510de0078f9bc7fc18dc179cceb62b</id>
<content type='text'>
Per RFC 3986 only the following characters are allowed in URIs unescaped:

unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims    = "!" / "$" / "&amp;" / "'" / "(" / ")"
              / "*" / "+" / "," / ";" / "="

And "%" can appear as a part of escaping itself.  The following
characters are not allowed and need to be escaped: %00-%1F, %7F-%FF,
" ", """, "&lt;", "&gt;", "\", "^", "`", "{", "|", "}".

Not escaping "&gt;" is known to cause problems at least with MS Exchange (see
http://nginx.org/pipermail/nginx-ru/2010-January/031261.html) and in
Tomcat (ticket #2191).

The patch adds escaping of the following chars in all URI parts: """, "&lt;",
"&gt;", "\", "^", "`", "{", "|", "}".  Note that comments are mostly preserved
to outline important characters being escaped.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Per RFC 3986 only the following characters are allowed in URIs unescaped:

unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims    = "!" / "$" / "&amp;" / "'" / "(" / ")"
              / "*" / "+" / "," / ";" / "="

And "%" can appear as a part of escaping itself.  The following
characters are not allowed and need to be escaped: %00-%1F, %7F-%FF,
" ", """, "&lt;", "&gt;", "\", "^", "`", "{", "|", "}".

Not escaping "&gt;" is known to cause problems at least with MS Exchange (see
http://nginx.org/pipermail/nginx-ru/2010-January/031261.html) and in
Tomcat (ticket #2191).

The patch adds escaping of the following chars in all URI parts: """, "&lt;",
"&gt;", "\", "^", "`", "{", "|", "}".  Note that comments are mostly preserved
to outline important characters being escaped.
</pre>
</div>
</content>
</entry>
<entry>
<title>Core: fixed comment about escaping in arguments.</title>
<updated>2021-06-28T15:01:09+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2021-06-28T15:01:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=31d1c34b394ee30b30084ff160133708d0d3b030'/>
<id>31d1c34b394ee30b30084ff160133708d0d3b030</id>
<content type='text'>
After 4954530db2af, the ";" character is escaped by
ngx_escape_uri(NGX_ESCAPE_ARGS).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After 4954530db2af, the ";" character is escaped by
ngx_escape_uri(NGX_ESCAPE_ARGS).
</pre>
</div>
</content>
</entry>
<entry>
<title>Core: fixed comment about msie_refresh escaping.</title>
<updated>2021-05-19T13:24:13+00:00</updated>
<author>
<name>Ruslan Ermilov</name>
<email>ru@nginx.com</email>
</author>
<published>2021-05-19T13:24:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=6029e211c63895c44a942bacc32c6d2f565cc3e3'/>
<id>6029e211c63895c44a942bacc32c6d2f565cc3e3</id>
<content type='text'>
After 12a656452ad1, the "%" character is no longer escaped by
ngx_escape_uri(NGX_ESCAPE_REFRESH).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After 12a656452ad1, the "%" character is no longer escaped by
ngx_escape_uri(NGX_ESCAPE_REFRESH).
</pre>
</div>
</content>
</entry>
<entry>
<title>Core: added format specifiers to output binary data as hex.</title>
<updated>2020-10-28T07:56:11+00:00</updated>
<author>
<name>Vladimir Homutov</name>
<email>vl@nginx.com</email>
</author>
<published>2020-10-28T07:56:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=3c0427373381097a9e25ccc2cb46bbc1ccac87a2'/>
<id>3c0427373381097a9e25ccc2cb46bbc1ccac87a2</id>
<content type='text'>
Now "s", "V", and "v" format specifiers may be prefixed with "x" (lowercase)
or "X" (uppercase) to output corresponding data in hexadecimal format.

In collaboration with Maxim Dounin.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now "s", "V", and "v" format specifiers may be prefixed with "x" (lowercase)
or "X" (uppercase) to output corresponding data in hexadecimal format.

In collaboration with Maxim Dounin.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fixed incorrect length handling in ngx_utf8_length().</title>
<updated>2019-04-15T17:14:07+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2019-04-15T17:14:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=f09eae2a7586c5149fe7eaa497c8ff1be684270f'/>
<id>f09eae2a7586c5149fe7eaa497c8ff1be684270f</id>
<content type='text'>
Previously, ngx_utf8_decode() was called from ngx_utf8_length() with
incorrect length, potentially resulting in out-of-bounds read when
handling invalid UTF-8 strings.

In practice out-of-bounds reads are not possible though, as autoindex, the
only user of ngx_utf8_length(), provides null-terminated strings, and
ngx_utf8_decode() anyway returns an errors when it sees a null in the
middle of an UTF-8 sequence.

Reported by Yunbin Liu.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, ngx_utf8_decode() was called from ngx_utf8_length() with
incorrect length, potentially resulting in out-of-bounds read when
handling invalid UTF-8 strings.

In practice out-of-bounds reads are not possible though, as autoindex, the
only user of ngx_utf8_length(), provides null-terminated strings, and
ngx_utf8_decode() anyway returns an errors when it sees a null in the
middle of an UTF-8 sequence.

Reported by Yunbin Liu.
</pre>
</div>
</content>
</entry>
<entry>
<title>Core: ngx_explicit_memzero().</title>
<updated>2018-11-15T18:28:02+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2018-11-15T18:28:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=6c3838f9ed45f5c2aa6a971a0da3cb6ffe45b61e'/>
<id>6c3838f9ed45f5c2aa6a971a0da3cb6ffe45b61e</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Fixed handling of non-null-terminated unix sockets.</title>
<updated>2017-10-04T18:19:38+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2017-10-04T18:19:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=cba23f88ec6740b7f8d6a1383254708a91d37625'/>
<id>cba23f88ec6740b7f8d6a1383254708a91d37625</id>
<content type='text'>
At least FreeBSD, macOS, NetBSD, and OpenBSD can return unix sockets
with non-null-terminated sun_path.  Additionally, the address may become
non-null-terminated if it does not fit into the buffer provided and was
truncated (may happen on macOS, NetBSD, and Solaris, which allow unix socket
addresess larger than struct sockaddr_un).  As such, ngx_sock_ntop() might
overread the sockaddr provided, as it used "%s" format and thus assumed
null-terminated string.

To fix this, the ngx_strnlen() function was introduced, and it is now used
to calculate correct length of sun_path.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
At least FreeBSD, macOS, NetBSD, and OpenBSD can return unix sockets
with non-null-terminated sun_path.  Additionally, the address may become
non-null-terminated if it does not fit into the buffer provided and was
truncated (may happen on macOS, NetBSD, and Solaris, which allow unix socket
addresess larger than struct sockaddr_un).  As such, ngx_sock_ntop() might
overread the sockaddr provided, as it used "%s" format and thus assumed
null-terminated string.

To fix this, the ngx_strnlen() function was introduced, and it is now used
to calculate correct length of sun_path.
</pre>
</div>
</content>
</entry>
<entry>
<title>Parenthesized ASCII-related calculations.</title>
<updated>2017-07-17T14:23:51+00:00</updated>
<author>
<name>Valentin Bartenev</name>
<email>vbart@nginx.com</email>
</author>
<published>2017-07-17T14:23:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=9197a3c8741a8832e6f6ed24a72dc5b078d840fd'/>
<id>9197a3c8741a8832e6f6ed24a72dc5b078d840fd</id>
<content type='text'>
This also fixes potential undefined behaviour in the range and slice filter
modules, caused by local overflows of signed integers in expressions.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This also fixes potential undefined behaviour in the range and slice filter
modules, caused by local overflows of signed integers in expressions.
</pre>
</div>
</content>
</entry>
</feed>
