Custom Query (2296 matches)

memcpying to or from NULL is undefined behavior, even when the copy is of size 0.

Nginx executes a memcpy from NULL during startup with the default configuration. This can be reproduced very easily as follows:

0. Build and install Nginx with GCC 12.2.0 on x86_64 Linux using the default configuration.
1. Run Nginx under gdb, setting the appropriate breakpoints:

   gdb -ex 'b ngx_pstrdup' -ex 'r' -ex 'c' -ex 'c' -ex 'b memcpy' -ex 'c' -ex 'print $rsi' /usr/local/nginx/sbin/nginx
   

2. Observe that the second argument to memcpy is NULL:

   GNU gdb (Debian 13.1-3) 13.1
   Copyright (C) 2023 Free Software Foundation, Inc.
   License GPLv3+: GNU GPL version 3 or later <LINK OMITTED>
   This is free software: you are free to change and redistribute it.
   There is NO WARRANTY, to the extent permitted by law.
   Type "show copying" and "show warranty" for details.
   This GDB was configured as "x86_64-linux-gnu".
   Type "show configuration" for configuration details.
   For bug reporting instructions, please see:
   <LINK OMITTED>.
   Find the GDB manual and other documentation resources online at:
       <LINK OMITTED>.
   
   For help, type "help".
   Type "apropos word" to search for commands related to "word"...
   Reading symbols from /usr/local/nginx/sbin/nginx...
   Breakpoint 1 at 0x1ea6c: file src/core/ngx_string.c, line 76.
   Starting program: /usr/local/nginx/sbin/nginx
   warning: Error disabling address space randomization: Operation not permitted
   [Thread debugging using libthread_db enabled]
   Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
   
   Breakpoint 1, ngx_pstrdup (pool=pool@entry=0x55c897c5e4d0, src=src@entry=0x7ffcbb97b358)
       at src/core/ngx_string.c:76
   76	{
   Continuing.
   
   Breakpoint 1, ngx_pstrdup (pool=pool@entry=0x55c897c5e4d0, src=src@entry=0x7ffcbb97b368)
       at src/core/ngx_string.c:76
   76	{
   Continuing.
   
   Breakpoint 1, ngx_pstrdup (pool=pool@entry=0x55c897c5e4d0, src=src@entry=0x7ffcbb97b348)
       at src/core/ngx_string.c:76
   76	{
   Breakpoint 2 at 0x7f3413660cc0: memcpy. (4 locations)
   Continuing.
   
   Breakpoint 2.3, __memcpy_avx_unaligned_erms ()
       at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:264
   264	../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
   $1 = 0
   

This was found with UBSan. I have tested it both on the development branch, as well as 1.22.1, and the issue is present in both.

Hello I've read same bugs here but they were closed so I open a new one since I believe its not logic condition.

nginx relevant config:

proxy_cache_background_update on;
proxy_cache_key                "$MOBILE$scheme$host$request_uri";
proxy_cache_lock               on;
proxy_cache_methods            GET HEAD;
proxy_cache_use_stale          timeout invalid_header updating http_429 http_500 http_502 http_503 http_504 http_403; # 

proxy_cache_valid              200 15s;
proxy_cache_valid              404 15s;

--- I create simple file 404.txt and doing curl two times:

curl https://x.x.x/404.txt -k -I
HTTP/2 200 
server: nginx
date: Sun, 26 Nov 2023 07:44:29 GMT
content-type: text/plain; charset=UTF-8
content-length: 6
x-powered-by: WP Rocket/3.10.3
cache-control: public
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-nginx-upstream-cache-status: MISS
accept-ranges: bytes

again:

HTTP/2 200 
server: nginx
date: Sun, 26 Nov 2023 07:44:31 GMT
content-type: text/plain; charset=UTF-8
content-length: 6
x-powered-by: WP Rocket/3.10.3
cache-control: public
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-nginx-upstream-cache-status: HIT
accept-ranges: bytes

As you see now the file is cached in nginx. Now I go and remove this file from server and doing curl again 4 times:

curl https://x.x.x/404.txt -k -I
HTTP/2 200 
server: nginx
date: Sun, 26 Nov 2023 07:45:27 GMT
content-type: text/plain; charset=UTF-8
content-length: 6
x-powered-by: WP Rocket/3.10.3
cache-control: public
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-nginx-upstream-cache-status: STALE
accept-ranges: bytes

HTTP/2 200 
server: nginx
date: Sun, 26 Nov 2023 07:45:29 GMT
content-type: text/plain; charset=UTF-8
content-length: 6
x-powered-by: WP Rocket/3.10.3
cache-control: public
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-nginx-upstream-cache-status: STALE
accept-ranges: bytes

HTTP/2 200 
server: nginx
date: Sun, 26 Nov 2023 07:46:34 GMT
content-type: text/plain; charset=UTF-8
content-length: 6
x-powered-by: WP Rocket/3.10.3
cache-control: public
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-nginx-upstream-cache-status: UPDATING
accept-ranges: bytes

HTTP/2 200 
server: nginx
date: Sun, 26 Nov 2023 07:46:48 GMT
content-type: text/plain; charset=UTF-8
content-length: 6
x-powered-by: WP Rocket/3.10.3
cache-control: public
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-nginx-upstream-cache-status: STALE
accept-ranges: bytes

nginx log:

10.15.1.15 - STALE [26/Nov/2023:10:25:24 +0200]  "HEAD /404.txt HTTP/2.0" 200 0 "-" "curl/7.74.0"

Now it stales forever, it never refresh. I tried to add/remove this config:

proxy_cache_valid              404 15s;

but it doesn't change the behavior. When I manually remove all cache files from nginx or if I add cache buster i.e:

curl https://x.x.x/404.txt?1=1

it begins to return 404.

10.15.1.15 - MISS [26/Nov/2023:10:27:05 +0200]  "HEAD /404.txt?1=1 HTTP/2.0" 404 0 "-" "curl/7.74.0"

Please advise how to proceed. Dmitry Sherman

When nginx is proxying smtp auth it always uses "AUTH PLAIN <base64-encoded-username-and-passsword>" when trying to authenticate, despite the backend only offers "AUTH LOGIN".

This is the traffic between nginx and the backend:

220 exchange-backend Microsoft ESMTP MAIL Service ready at Mon, 20 Nov 2023 12:15:10 +0100
EHLO localhost
250-exchange-backend Hello [10.0.0.11]
250-SIZE 37748736
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-AUTH LOGIN
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 SMTPUTF8
AUTH PLAIN dGVzdAAxMjM0Cg==
504 5.7.4 Unrecognized authentication type