#2080 closed defect (invalid)
Possible mem leak in nginx
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | major | Milestone: | nginx-1.19 |
| Component: | other | Version: | 1.19.x |
| Keywords: | Memleak | Cc: | sungguoshuai@… |
| uname -a: | Linux localhost.localdomain 4.19.140-2009.4.0.0048.oe1.aarch64 #1 SMP Thu Sep 24 09:39:08 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.18.0
built by gcc 9.3.1 (GCC) built with OpenSSL 1.1.1f 31 Mar 2020 TLS SNI support enabled configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_v2_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_slice_module --with-http_perl_module=dynamic --with-http_auth_request_module --with-mail=dynamic --with-mail_ssl_module --with-pcre --with-pcre-jit --with-stream=dynamic --with-stream_ssl_module --with-google_perftools_module --with-debug --with-cc-opt='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/openEuler/openEuler-hardened-cc1 -fasynchronous-unwind-tables -fstack-clash-protection' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/openEuler/openEuler-hardened-ld -Wl,-E |
||
Description
When I use oss-fuzz to check the latest nginx source code,I get some possible mem leak problem(The function stack see as files).However, I'm not sure whether the code is caused by OSS_FUZZ or the nginx source code.It confused me so much.
The code is from http://hg.nginx.org/nginx/file/tip,
the oss-fuzz can be found at https://github.com/google/oss-fuzz/tree/master/projects/nginx/fuzz
In addition,I have check the latest nginx code and 1.18.0 has the same problem
At last,my test command(may be useless) is:
python infra/helper.py build_fuzzers --sanitizer address nginx
python infra/helper.py run_fuzzer nginx http_request_fuzzer
Attachments (1)
Change History (8)
by , 4 years ago
| Attachment: | sgs-nginx_latest.log added |
|---|
comment:1 by , 4 years ago
The 'uname -a' tell is aarch64, but I check the source code, x86_64 has the same code.
comment:2 by , 4 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
The leaks shown are clearly caused by oss-fuzz.
comment:3 by , 4 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
comment:4 by , 4 years ago
| Resolution: | → invalid |
|---|---|
| Status: | reopened → closed |
comment:5 by , 4 years ago
Thank you for your reply,sir.
But I don't understandard why you think this is 'clearly' caused by oss-fuzz,I will appreciate it if you can tell me the reason.
comment:6 by , 4 years ago
Stack traces provided show request pools allocated as leaked. These request pools are created for emulated connections created by http_request_fuzzer.cc, and the emulation layer does not seem to even try to provide working timers, not to mention events. Given that, there are no reasons to think that any requests created by this emulation layer will be freed, except may be in some simple cases when request handling can be completed immediately.
comment:7 by , 4 years ago
OK,thank you very much, dear Maxim~
I know the reason now,and I will soon seek help from the oss-fuzz community to refine the testcase.
Thank you again.
The full function stack of possible mem leak