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
string buffer overflow #1222
string buffer overflow #1222
Conversation
…ring is longer than the specified length. Instead of extracting just the specified substring, it copies the full string to the smaller buffer, corrupting the heap beyond the buffer.
@@ -217,7 +217,8 @@ String & String::copy(const char *cstr, unsigned int length) | |||
return *this; | |||
} | |||
len = length; | |||
strcpy(buffer, cstr); | |||
memcpy(buffer, cstr, length); | |||
buffer[len] = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might it not be clearer if it was buffer[len] = '\0';
? My C/C++ knowledge is woefully behind y'all's so sorry if the suggestion is silly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They are the same thing, but I agree most people see a null terminator and know what's going on without thinking about it. Sometimes the way to go though is to match the style used in the existing file instead of applying your own style here and there. In that light, most of the file uses = 0;
and there are only two instances of = '\0';
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem isn't null terminating the local buffer, but that it's copying too much data into the buffer. We can't null terminate the cstr
at the given length since that's input data (and const).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see what you mean, Using a char instead of an int. Sure we can do that.
Nice catch Mat! Looks good and fixed and I'd love to see a test added to keep it that way. |
I was unsure how to test it when I found the bug (how to test corrupt heap?) but on reflection it's simple. If we can pre-size the internal buffer to be larger than the input string (say 10 chars) and then provide a string that is 7 chars long, with a length of 5, then we verify that only 5 chars were copied to the buffer, and not 7. (And with the buffer being larger, there is no memory corruption so we don't corrupt the test runner.) I'll add this test when I'm back from vacation (if someone doesn't beat me to it.) |
Nice catch, Mat. I'll add the test, since, after all, I was the one who added that constructor to the |
Thank you for for stepping up - much appreciated! Yes, it's surprising that the provided While you're working on this, could you check with the arduino String implementation to see if there are any bugfixes made since our code was forked. There might be other bombs lurking waiting to go off :-) |
Hey @technobly, I've added API tests for the As for the unit test discussed above, at closer look I don't see how it can be implemented without changing Considering that current coverage of |
Sounds good, I captured this in the merging notes for 0.6.1-rc.2 |
fixes bug in
String(const char* str, int len)
constructor when the string is longer than the specified length. Instead of extracting just the specified substring, it copies the full string to the smaller buffer, corrupting the heap beyond the buffer.Doneness:
Bugfixes
String(const char* str, int len)
constructor when the string is longer than the specified length.