Fix univalue handling of \u0000 characters. #6266

Merged
merged 1 commit into from Jun 12, 2015

Conversation

Projects
None yet
4 participants
@domob1812
Contributor

domob1812 commented Jun 10, 2015

Univalue's parsing of \u escape sequences did not handle NUL characters correctly. They were, effectively, dropped. The extended test-case fails with the old code, and is fixed with this patch.

domob1812 added a commit to domob1812/namecore that referenced this pull request Jun 10, 2015

Merge branch 'auxpow'
Currently, the rest.py test fails due to a bug in Univalue with NUL
characters.  This will, hopefully, be fixed upstream in Bitcoin soon.
See my patch:

  bitcoin/bitcoin#6266

Conflicts:
	contrib/gitian-descriptors/gitian-linux.yml
	src/init.cpp
	src/rpcrawtransaction.cpp
	src/rpcserver.cpp
	src/rpcserver.h
	src/test/Checkpoints_tests.cpp
	src/wallet/rpcwallet.cpp
@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Jun 10, 2015

Member

Thanks for thinking about NUL characters, they're a pet peeve of mine.
utACK

Member

laanwj commented Jun 10, 2015

Thanks for thinking about NUL characters, they're a pet peeve of mine.
utACK

@laanwj laanwj added the RPC/REST/ZMQ label Jun 10, 2015

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Jun 10, 2015

Contributor

Concept ACK - IMO this needs a really close review to ensure you don't overflow e.g. the buf that shrank from 4 to 3

Contributor

jgarzik commented Jun 10, 2015

Concept ACK - IMO this needs a really close review to ensure you don't overflow e.g. the buf that shrank from 4 to 3

@laanwj

View changes

src/univalue/univalue_read.cpp
@@ -188,7 +188,7 @@ enum jtokentype getJsonToken(string& tokenVal, unsigned int& consumed,
case 't': valStr += "\t"; break;
case 'u': {
- char buf[4] = {0,0,0,0};
+ char buf[3];

This comment has been minimized.

@laanwj

laanwj Jun 11, 2015

Member

This absolutely needs review, but the changes look very sane to me. The buffer size is decreased from 4 to 3 because the last slot was only there to hold a terminating NUL character. This is no longer necessary because the new code counts characters. If this has an overflow bug, it was already there.

I wonder one thing though: could we push_back the characters into valStr directly instead of the intermediate buf? This would avoid any overflow risk.

@laanwj

laanwj Jun 11, 2015

Member

This absolutely needs review, but the changes look very sane to me. The buffer size is decreased from 4 to 3 because the last slot was only there to hold a terminating NUL character. This is no longer necessary because the new code counts characters. If this has an overflow bug, it was already there.

I wonder one thing though: could we push_back the characters into valStr directly instead of the intermediate buf? This would avoid any overflow risk.

This comment has been minimized.

@domob1812

domob1812 Jun 11, 2015

Contributor

Exactly that was my rationale. The buffer will only ever be accessed in the iterator range [buf, last), and last itself is incremented at most three times.

However, I like your suggestion of using push_back directly! I think that makes sense and will rewrite the code accordingly.

@domob1812

domob1812 Jun 11, 2015

Contributor

Exactly that was my rationale. The buffer will only ever be accessed in the iterator range [buf, last), and last itself is incremented at most three times.

However, I like your suggestion of using push_back directly! I think that makes sense and will rewrite the code accordingly.

Fix univalue handling of \u0000 characters.
Univalue's parsing of \u escape sequences did not handle NUL characters
correctly.  They were, effectively, dropped.  The extended test-case
fails with the old code, and is fixed with this patch.
@domob1812

This comment has been minimized.

Show comment
Hide comment
@domob1812

domob1812 Jun 11, 2015

Contributor

I've changed the patch to directly push the characters onto the result instead of using the temporary buffer. This should be cleaner and less prone to potential overflow bugs.

Contributor

domob1812 commented Jun 11, 2015

I've changed the patch to directly push the characters onto the result instead of using the temporary buffer. This should be cleaner and less prone to potential overflow bugs.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Jun 11, 2015

Member

Thanks. re-utACK

Member

laanwj commented Jun 11, 2015

Thanks. re-utACK

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Jun 11, 2015

Contributor

ACK

Contributor

jgarzik commented Jun 11, 2015

ACK

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Jun 11, 2015

Member

Tested & reviewed ACK

Member

jonasschnelli commented Jun 11, 2015

Tested & reviewed ACK

@laanwj laanwj merged commit 0cc7b23 into bitcoin:master Jun 12, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

laanwj added a commit that referenced this pull request Jun 12, 2015

Merge pull request #6266
0cc7b23 Fix univalue handling of \u0000 characters. (Daniel Kraft)

@domob1812 domob1812 deleted the domob1812:fix-univalue-nul branch Jun 12, 2015

@str4d str4d referenced this pull request in zcash/zcash Feb 14, 2017

Merged

Bitcoin 0.12 RPC PRs 1 #2100

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment