[SERVER-3760] potentially unsafe use of memcmp in v1 index Created: 05/Sep/11 Updated: 11/Jul/16 Resolved: 06/Sep/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance |
| Affects Version/s: | None |
| Fix Version/s: | 2.0.0-rc2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Aaron Staple | Assignee: | Dwight Merriman |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Participants: |
| Description |
|
I don't think memcmp guarantees that it will not access later bytes in a string if earlier bytes do not match. According to the man page "Both strings are assumed to be n bytes long." So for example if there is a memcmp implementation that compares one word rather than one byte at a time and backtracks to find the return value if there is a mismatch it could seg fault in the following call sites where the allocation for r may be shorter than sz/len. case cstring: { unsigned sz = ((unsigned) *l) + 1; if( memcmp(l, r, sz) ) // first byte checked is the length byte return false; l += sz; r += sz; break; }case cbindata: { int len = binDataCodeToLength(*l) + 1; if( memcmp(l, r, len) ) return false; l += len; r += len; break; } |
| Comments |
| Comment by Dwight Merriman [ 06/Sep/11 ] |
|
pls review aaron tx. |
| Comment by auto [ 06/Sep/11 ] |
|
Author: {u'login': u'dwight', u'name': u'dwight', u'email': u'dwight@10gen.com'}Message: |
| Comment by Dwight Merriman [ 06/Sep/11 ] |
|
ah right. looks like it is ok everywhere except woEqual. will look into. |