Issue from the past that still looks unresolved

[ayavilevich]

Hi, I see that the library is in more active development lately. Thumbs up!

I used the library previously and there was this bug in the json deserialization step where it treated the pointer to the body buffer as a null terminated string. See me-no-dev#807
Normally it isn't an issue because the parsing will end before out of bounds when it gets the closing } . However, if the buffer is not a valid json then it will try to continue parsing out of bounds and can lead to a crash or unexpected behavior.
I had a patch for this as specified in issue 807. You basically pass the size of the data as an optional parameter.

Maybe now is a time to revisit this issue and address it in the repository? I think the problematic code is still there. wdyt?

[mathieucarbou]

I think that this problem is 5 years old, and if it still exists, you first need to come with a MRE to reproduce it even before thinking of a fix.

[ayavilevich]

Well, that is a difficult ask. This issue will only happen if the memory space after the allocated _tempObject buffer is full of not-nulls or some other specific content. After all this is an out-of-bounds read issue. Not sure yet how one can reproduce this reliably. Perhaps with stress testing.
However you can see the problem in two different ways.
Take https://github.com/ESP32Async/ESPAsyncWebServer/blob/main/examples/Json/Json.ino as the code in both cases.

1:
Edit AsyncCallbackJsonWebHandler::handleRequest in AsyncJson.cpp and add:
Serial.printf("deser: strlen: %d, buf len: %d\n", strlen((const char *)(request->_tempObject)), request->contentLength()); before the call to deserializeJson.
Invoke with curl -v -X POST -H 'Content-Type: application/json' -d '{"name":"You"}' http://192.168.4.1/json2 and you should see that the strlen is larger than buf len.

2:
Invoke with curl -v -X POST -H 'Content-Type: application/json' -d '5' http://192.168.4.1/json2 . I expect you to get an error. However, 5 is a valid json string that should deserialize to a scalar. The deserialization fails because the program is trying to deserialize "5[junk]" instead.
Add the proper size to deserializeJson per me-no-dev#807 and deserialization will now work.

[mathieucarbou]

@ayavilevich : when you say: you should see... Do you mean that you can see this behaviour happening with the current libs ?

Look... I do not want, and we have no time to spend on trying to bust an issue that might not be there anymore from 5y back.

So please like I said, if you see it with the current libs, or can provide a way to reproduce, then comment back to this discussion.
Otherwise the conversation is closed and there is no issue... at least until one is found.

[ayavilevich]

Yes. It still happens. The issue is still present.
I understand prioritization and appreciate your time maintaining the package.
I submitted a proper issue and PR. Hope it makes it easier. If I can help in any way LMK.

#183
#184

[mathieucarbou]

Thank you for the effort! Will look into it!