[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: SERVER-3760 fix memcmp to now potentially go to far on one of the input arrays.
in addition fix a case where compare order of bindata types, when subtype and len, were in consistent
with BSONObj's compare. this ordering is somewhat arbitrary but must be consistent.
Branch: master
https://github.com/mongodb/mongo/commit/210e12a17a04fa27c3fa0ae66cdff2b4e78ba605

Comment by Dwight Merriman [ 06/Sep/11 ]

ah right. looks like it is ok everywhere except woEqual. will look into.

Generated at Thu Feb 08 03:03:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.