-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
Crash when trying to create buffers with invalid base64. #3496
Comments
/cc @trevnorris |
I can reproduce this. |
I can confirm that this also crashes on Amazon Linux AMI:
It did not crash on OS X for me. |
Just FYI, this also crashes on FreeBSD 10.1-RELEASE:
That's using node.js v4.2.1 from ports. |
@bnoordhuis - your PR seem to solve the crash which happens when failing to parse a string with output > 4096 (base64 input > 5641). |
It'd be nice to throw an exception if invalid base64 was passed into Right now though, I just want node to not crash. |
malloc(0) and realloc(ptr, 0) have implementation-defined behavior in that the standard allows them to either return a unique pointer or a nullptr for zero-sized allocation requests. Normalize by always using a nullptr. Fixes: nodejs#3496 PR-URL: nodejs#3499 Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: Trevor Norris <trev.norris@gmail.com>
@jhamhader The base64 decoder's behavior is backwards compatible (going back all the way to v0.1.x, IIRC.) It's allowed to pass in base64 data with trailing gunk and (some) interior gunk. To wit, one of my first contributions to node was a better base64 decoder. One of my first bug fixes was for the regression it introduced because it was too strict. :-) If you want to ensure that all input has been decoded, you would have to validate it yourself. Assuming valid base64 without whitespace, the decoded size should be |
malloc(0) and realloc(ptr, 0) have implementation-defined behavior in that the standard allows them to either return a unique pointer or a nullptr for zero-sized allocation requests. Normalize by always using a nullptr. Fixes: #3496 PR-URL: #3499 Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: Trevor Norris <trev.norris@gmail.com>
malloc(0) and realloc(ptr, 0) have implementation-defined behavior in that the standard allows them to either return a unique pointer or a nullptr for zero-sized allocation requests. Normalize by always using a nullptr. Fixes: #3496 PR-URL: #3499 Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: Trevor Norris <trev.norris@gmail.com>
malloc(0) and realloc(ptr, 0) have implementation-defined behavior in that the standard allows them to either return a unique pointer or a nullptr for zero-sized allocation requests. Normalize by always using a nullptr. Fixes: #3496 PR-URL: #3499 Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By: Trevor Norris <trev.norris@gmail.com>
I've been having this problem intermittently in production, and (with the help of @kans) managed to create a reproducible test case. This is on Ubuntu 15.04 using node.js v4.2.1 (built from source):
In the Buffer constructor (https://github.com/nodejs/node/blob/master/src/node_buffer.cc#L224), it looks like
StringBytes::Write()
fails and returns zero. Thenrealloc()
is called with a length of zero. On linux, this frees the memory and returns a null pointer. Then the null assertion fails and node crashes.realloc()
behaves differently on OS X, so this won't crash on a mac.The text was updated successfully, but these errors were encountered: