Fixes stream load memory leak in WifiSecureClient for SSL CACert, Certificate, and Private Key

[beeboopx]

Summary

This PR fixes massive memory leak in WifiSecureClient when stream loading the TLS CACert, Certificate, and Private Key.

Issue is not presented on the first load. Issue presents during all subsequent invocations of loadCACert, loadCertificate, and loadPrivateKey, respectively.

Issue was verified to exist and changes verified to work by printing the available heap once per second in my application and following the below procedure.

Issue verified by:

1. First connect to a WiFi network, establish a TLS session utilizing loadCACert + loadCertificate + loadPrivateKey. Once session is established, note the free heap.
2. Disable WiFi network, and the TLS session is ended.
3. Re-Enable WiFi network, establish a new TLS session utilizing loadCACert + loadCertificate + loadPrivateKey again. Once session is established, note the free heap has permanently decreased by the size of the CA, Cert, and Private Key char arrays. In my case, this was about 5kB decrease on every new session established.

Fix verified by:

1. First connect to a WiFi network, establish a TLS session utilizing loadCACert + loadCertificate + loadPrivateKey. Once session is established, note the free heap.
2. Disable WiFi network, and the TLS session is ended.
3. Re-Enable WiFi network, establish a new TLS session utilizing loadCACert + loadCertificate + loadPrivateKey again. Once session is established, the free heap no longer decreases as before fix applied.

Impact

Fixes above summarized memory leak in WifiClientSecure.cpp and does nothing else.

Related links

• Fixes Memory leak on multiple calls to loadCACert and others on WiFiClientSecure #5826

• Takes a different approach than Fix memory leak on stream load when updating CA Certificate #6062 which did not pass compile checks and included other changes unrelated to the raised issue.

[CLAassistant]

All committers have signed the CLA.

[beeboopx]

Hmmm it's working well for initial load, and if same cert is reloaded again, but if there is a different cert loaded it will panic with:

assert failed: heap_caps_realloc heap_caps.c:345 (heap != NULL && "free() pointer is outside heap areas")

i will investigate a bit more and push another commit with fixes.

Anyone have any ideas on this?

[mrengineer7777]

Possibly related:
#6062
#6055

[timr49]

Hmmm it's working well for initial load, and if same cert is reloaded again, but if there is a different cert loaded it will panic with:

assert failed: heap_caps_realloc heap_caps.c:345 (heap != NULL && "free() pointer is outside heap areas")

i will investigate a bit more and push another commit with fixes.

Anyone have any ideas on this?

Feedback on proposed fix:

1. In each of these three cases, if _streamLoad() returns null (e.g. because the stream has insufficient data available or malloc() fails) then _CA_cert/_cert/_private_key etc. are left pointing to space that has now been free()d. Suggest that between each call to free() and the following _streamLoad(), the member just free()d is set to null.2.

2. _CA_cert/_cert/_private_key may have been passed by the calling application via setCACert/setCertificate/setPrivateKey in which case the calling application would (should?) be free()ing them, leading to the same space being free()d twice.

3. There are still opportunities for memory leaks. For example ...

(a) the destructor for WiFiClientSecure does not appear to free any of these things. For example, if the example was changed to instantiate a new WiFiClientSecure object each time, it would get the some amount of leakage.

(b) a call to setInsecure() will leak any of these things that have previously been allocated;

5. note that the solution is not as simple as free()ing them in ~WiFiClientSecure() etc. because they may have been allocated by the calling application and passed via calls to setCACert/setCertificate/setPrivateKey, in which case the calling application will be expecting to free() them.

6. therefore, a solution needs allocator/reallocator/deallocator methods which take account of how they were previously allocated (or not), deallocates if appropriate before allocating/reallocating, and which deallocates when ~WiFiClientSecure() (or Insecure() or anything else that currently just assigns null) are called.

[github-actions]

Unit Test Results

0 files  0 suites   0s ⏱️
0 tests 0 ✔️ 0 💤 0 ❌

Results for commit 46bf03c.

[me-no-dev]

Hi @fillybrese ! It is always good to make sure that we do not leak any memory. Thanks for the contribution!

[TD-er]

I only now noticed this PR...
I think there are multiple other issues here, especially with the mbedtls data structure.
This one isn't initialized correct, so the internal members may still contain random data resuling in pointers not being null and thus cause crashes when destructing the structure.
I did mention this several times in related issues.
See also the 4 "Helpers/ESPEasy_xxx" files in this PR: https:/letscontrolit/ESPEasy/pull/3788/files#diff-e1489f0e20f34ec2d70451ffec1baaeeac1c789eb4c2dc54219e75e5ea6c10d5
These are copy/paste versions of the files in this repository, but including changes.

What happens is if a connection is failed and retried, then you may run into these issues. Partly fixed in this PR, but not in the other files (as far as I know)

[beeboopx]

Thank you @mrengineer7777 @timr49 @me-no-dev @TD-er for your feedback on the PR. I will review the feedback and implement the changes as soon as i can. Just have been short on time recently, will do my best.

There were the issues discovered by myself and others in the original PR code. I would have recommended merging to master be delayed until these raised points are addressed.

[mrengineer7777]

I will review the feedback and implement the changes as soon as i can. Just have been short on time recently, will do my best.

There were the issues discovered by myself and others in the original PR code. I would have recommended merging to master be delayed until these raised points are addressed.

Understood. Your PR was helpful, so can't complain about the merge. Create a new PR to address the remaining issues when you have a chance. Thanks in advance for your contribution!