Skip to content

Fix possible memory leak on TLS handshake failure - #796

Merged
JelteF merged 1 commit into
masterfrom
fix-memory-leak-on-tls-handshake-failure
Jan 3, 2023
Merged

Fix possible memory leak on TLS handshake failure#796
JelteF merged 1 commit into
masterfrom
fix-memory-leak-on-tls-handshake-failure

Conversation

@JelteF

@JelteF JelteF commented Dec 23, 2022

Copy link
Copy Markdown
Member

On an unrelated PR a memory leak was reported by CI on a TLS test.

==11838== VALGRIND-ERROR-BEGIN
==11838== 71,890 (112 direct, 71,778 indirect) bytes in 1 blocks are definitely lost in loss record 178 of 178
==11838==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==11838==    by 0x15B06E: tls_new (tls.c:240)
==11838==    by 0x16210B: tls_server_conn (tls_server.c:47)
==11838==    by 0x16248E: tls_accept_fds (tls_server.c:141)
==11838==    by 0x1380EB: sbuf_tls_accept (sbuf.c:1127)
==11838==    by 0x11E15A: handle_client_startup (client.c:729)
==11838==    by 0x11EF17: client_proto (client.c:1041)
==11838==    by 0x136069: sbuf_call_proto (sbuf.c:390)
==11838==    by 0x136B58: sbuf_process_pending (sbuf.c:583)
==11838==    by 0x13722C: sbuf_main_loop (sbuf.c:763)
==11838==    by 0x134FAB: sbuf_accept (sbuf.c:137)
==11838==    by 0x12D220: accept_client (objects.c:1540)
==11838==
==11838== VALGRIND-ERROR-END

Source: https://cirrus-ci.com/task/5909005202096128?logs=test#L91

When running the same test multiple times locally on my own machine this
reproduced ~100 runs. After adding some logging the reason turned out to
be that we were not always handling errors from handle_tls_handshake.

This PR fixes that by handling handshake errors in all places that we
call handle_tls_handshake. I confirmed this fixed the issue by running
the originally failing test 1000 times with valgrind and all runs passed
now.

On an unrelated PR a memory leak was reported by CI on a TLS test.
```
==11838== VALGRIND-ERROR-BEGIN
==11838== 71,890 (112 direct, 71,778 indirect) bytes in 1 blocks are definitely lost in loss record 178 of 178
==11838==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==11838==    by 0x15B06E: tls_new (tls.c:240)
==11838==    by 0x16210B: tls_server_conn (tls_server.c:47)
==11838==    by 0x16248E: tls_accept_fds (tls_server.c:141)
==11838==    by 0x1380EB: sbuf_tls_accept (sbuf.c:1127)
==11838==    by 0x11E15A: handle_client_startup (client.c:729)
==11838==    by 0x11EF17: client_proto (client.c:1041)
==11838==    by 0x136069: sbuf_call_proto (sbuf.c:390)
==11838==    by 0x136B58: sbuf_process_pending (sbuf.c:583)
==11838==    by 0x13722C: sbuf_main_loop (sbuf.c:763)
==11838==    by 0x134FAB: sbuf_accept (sbuf.c:137)
==11838==    by 0x12D220: accept_client (objects.c:1540)
==11838==
==11838== VALGRIND-ERROR-END
```
Source: https://cirrus-ci.com/task/5909005202096128?logs=test#L91

When running the same test multiple times locally on my own machine this
reproduced ~100 runs. After adding some logging the reason turned out to
be that we were not always handling errors from `handle_tls_handshake`.

This PR fixes that by handling handshake errors in all places that we
call `handle_tls_handshake`. I confirmed this fixed the issue by running
the originally failing test 1000 times with valgrind and all runs passed
now.

@eulerto eulerto left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. LGTM.

@JelteF
JelteF merged commit 11a5bbc into master Jan 3, 2023
@JelteF
JelteF deleted the fix-memory-leak-on-tls-handshake-failure branch January 3, 2023 13:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants