Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Fix null pointer dereference in set_ssl_ctx#1727

Open
moon044 wants to merge 2 commits intocoturn:masterfrom
moon044:fix-null-deref-set-ssl-ctx
Open

Fix null pointer dereference in set_ssl_ctx#1727
moon044 wants to merge 2 commits intocoturn:masterfrom
moon044:fix-null-deref-set-ssl-ctx

Conversation

@moon044
Copy link

@moon044 moon044 commented Jul 23, 2025

What this fixes

Hi,
This PR addresses a potential NULL pointer dereference in src/apps/relay/netengine.c.
In the function set_ssl_ctx(), malloc() may return NULL under low-memory conditions, but this was not checked.
As a result, the server could crash by dereferencing a NULL pointer.

Why this is important

If the system runs out of memory and malloc() fails, dereferencing the result causes a crash, leading to a denial of service.
This kind of failure is critical in production TURN deployments where uptime and availability are essential.

What this PR does

Adds a straightforward NULL check after malloc() and logs an error if allocation fails.
The function's logic remains unchanged — this is a minimal, defensive improvement for stability without any functional side effects.

Thanks for your consideration. I look forward to your feedback.

@eakraly
Copy link
Collaborator

eakraly commented Jul 26, 2025

Thank you @moon044
This PR makes sense but I doubt it adds any protection - this method is called on setting up turnserver

It would be great though to test turnserver under memory stress - there are probably other places in code where memory allocation is protected but the logic farther does not handle it properly

@moon044
Copy link
Author

moon044 commented Jul 27, 2025

Thanks for the review and thoughtful feedback, @eakraly !

You're absolutely right — this is during startup so the real-world impact is probably minimal.

I ran infer on the codebase and found this plus another similar NULL dereference issue in netengine.c:
a realloc() result is assigned to relay_addrs and immediately dereferenced without checking for NULL.

I understand these are minor defensive improvements rather than critical fixes. Should I include the second finding in this PR as well, or handle them separately?

Thanks again!

@eakraly
Copy link
Collaborator

eakraly commented Aug 14, 2025

@moon044 you can include it in this one. Thanks!

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.

3 participants