Re: BUG #16160: Minor memory leak in case of starting postgres server with SSL encryption
Jelte Fennema-Nio <postgres@jeltef.nl>
From: Jelte Fennema <postgres@jeltef.nl>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, duspensky@ya.ru,
pgsql-bugs@lists.postgresql.org
Date: 2021-03-16T17:17:49Z
Lists: pgsql-bugs
I'm pretty sure it was the only cause in this specific case. When running postgres with valgrind this was the only block that was repeatedly being leaked. Originally we also thought that root_cert_list could be the cause. Changing the size of the root cert did not speed up the memory leak though, so this was rejected as one of the causes (before we ran postgres with valgrind). The reason it doesn't leak is that root_cert_list gets added to the SSL_CTX a little while after creation if everything goes well. Looking at it again now, I see that if an error occurs when parsing ssl_crl_file the root_cert_list is in fact leaked. This was easy to reproduce by specifying a bogus path for ssl_crl_file. Running postgres again with valgrind then yields this leak (when stopping it after 47 SIGHUPs): ==13061== 30,738 (1,504 direct, 29,234 indirect) bytes in 47 blocks are definitely lost in loss record 147 of 148 ==13061== at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==13061== by 0x5825F08: CRYPTO_zalloc (build_shared/../crypto/mem.c:230) ==13061== by 0x588702E: OPENSSL_sk_new_reserve (build_shared/../crypto/stack/stack.c:209) ==13061== by 0x544D644: sk_X509_NAME_new_null (build_shared/../include/openssl/x509.h:77) ==13061== by 0x544D644: SSL_load_client_CA_file (build_shared/../ssl/ssl_cert.c:634) ==13061== by 0x3F814D: be_tls_init (home/jelte/.pgenv/src/postgresql-11.10/src/backend/libpq/be-secure-openssl.c:221) ==13061== by 0x3E65F0: secure_initialize (home/jelte/.pgenv/src/postgresql-11.10/src/backend/libpq/be-secure.c:77) ==13061== by 0x4973C5: SIGHUP_handler (home/jelte/.pgenv/src/postgresql-11.10/src/backend/postmaster/postmaster.c:2603) ==13061== by 0x4E5097F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.27.so) ==13061== by 0x6C8FDD6: select (build/glibc-S9d2JN/glibc-2.27/misc/../sysdeps/unix/sysv/linux/select.c:41) ==13061== by 0x49B50E: ServerLoop (home/jelte/.pgenv/src/postgresql-11.10/src/backend/postmaster/postmaster.c:1692) ==13061== by 0x49C9F7: PostmasterMain (home/jelte/.pgenv/src/postgresql-11.10/src/backend/postmaster/postmaster.c:1401) ==13061== by 0x3F947A: main (home/jelte/.pgenv/src/postgresql-11.10/src/backend/main/main.c:228) Parsing our ssl_crl_file did not cause errors though, so in our case this was not the cause.
Commits
-
Fix memory leak when rejecting bogus DH parameters.
- ad6c19066d93 10.17 landed
- 8c830148d2d4 11.12 landed
- 2f31414f4322 12.7 landed
- 4b41f6923458 13.3 landed
- e835e89a0fd2 14.0 landed
-
Fix memory leak when initializing DH parameters in backend
- c49e287a8e4d 11.12 landed
- 992cba94d38e 12.7 landed
- 7d9629ed2f69 10.17 landed
- e0e569e1d192 13.0 landed
-
Avoid corner-case memory leak in SSL parameter processing.
- 4b12ab18c9d0 14.0 landed
- a2764d87df04 11.12 landed
- 7ce7f2b79890 10.17 landed
- 6e34755560aa 12.7 landed
- 4d072bf2a031 13.3 landed