-
Notifications
You must be signed in to change notification settings - Fork 7.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
esp-mqtt: With TLS enabled large messages cause memory corruption on ESP32-C3 (IDFGH-10684) #11910
Comments
I dumped 1MiB on my vanilla ESP32 running the mqtt/ssl example and aside from the server disconnecting it due to lack of PINGREQ, it works fine. |
I can confirm, it works on an ESP32 (AI ESP32-S module). Same program on ESP32C3 failed. |
@mistoll I wasn't able to reproduce the issue. |
Here's my project stripped down to the minimum: mqtttest.zip All private data has been replaced with "AAAAAA". IDF is on cbce221 (v5.1) |
When testing the code I noticed that the error only happens with a single mqtt broker implementation. So I tried a view:
Other clients work with all brokers. I won't close this issue myself, as a panic caused by a faulty server is still an issue. However from my personal point of view, this can be closed. If you with to investigate further I can provide a public MQTTNet broker instance. |
Closing since I couldn't reproduce. |
Answers checklist.
IDF version.
v5.1
Operating System used.
Windows
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
ESP32-C3-WROOM-02
Power Supply used.
Battery
What is the expected behavior?
When a large message is received I expect it to be dispatched to mqtt_event_handler in chunks. This is the way it behaves when TLS is disabled.
What is the actual behavior?
When a large message (larger than 16330bytes) is received the memory get corrupted. If the message is large enough a panic is raised.
Steps to reproduce.
Debug Logs.
More Information.
This looks like a buffer overflow to me. It could even be a security issue.
The rx buffer of mbedtls is 16384. This is pretty close to the message size. So together with some encryption overhead this could be the buffer which is overflowing.
The text was updated successfully, but these errors were encountered: