-
Type:
Sub-task
-
Resolution: Unresolved
-
Priority:
Unknown
-
None
-
Affects Version/s: None
-
Component/s: None
-
0
-
Not Needed
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Deserializer test that throws wrong error when objectSize is negative:
it('throws a precise error when the scope document size field is negative', () => {
// Craft a code_w_scope element whose scope objectSize = -1.
//
// The totalSize cross-check computes:
// 4 (totalSize field) + 4 (string_size field) + stringSize + objectSize
// With stringSize = 6 ("hello\0") and objectSize = -1:
// 4 + 4 + 6 + (-1) = 13, which equals totalSize = 13.
// Both inequality guards pass, and 13 also clears the minimum-length check (>= 13).
//
// Without the objectSize <= 0 guard the frame is created with lastIndex = _index - 1.
// Since lastIndex is already behind the current index, the outer null terminator is
// consumed by the scope's terminator check, which fails the exact-match (index !== lastIndex)
// and throws 'Bad BSON Document: object not properly terminated' — pointing at the outer
// document rather than the malformed scope size field. The fix produces a precise error
// from the right layer instead.
const buf = bufferFromHexArray([
'0f', // BSON_DATA_CODE_W_SCOPE
'6600', // key 'f' + null
int32LEToHex(13), // totalSize = 4+4+6+(-1) = 13
int32LEToHex(6), // code string length = 6 ("hello" + null)
'68656c6c6f00', // code string "hello\0"
'ffffffff' // scope objectSize = -1 — the malicious value
]);
expect(() => BSON.deserialize(buf)).to.throw(BSON.BSONError, 'bad scope document size');
});
Use Case
As a... (who is this for)
I want... (what is the desired change)
So that... (why is the change desired)
User Experience
- What is the desired/expected outcome for the user once this ticket is implemented?
- If bug: What is the number of impacted customers? How severe is the impact? Is anyone blocked or broken?
Dependencies
- upstream and/or downstream requirements and timelines to bear in mind
Risks/Unknowns
- What could go wrong while implementing this change? (e.g., performance, inadvertent behavioral changes in adjacent functionality, existing tech debt, etc)
- Is there an opportunity for better cross-driver alignment or testing in this area?
- Is there an opportunity to improve existing documentation on this subject?
Acceptance Criteria
Implementation Requirements
- functional reqs, potential snafus to avoid, performance targets, etc
Testing Requirements
- unit test, spec test sync, etc
Documentation Requirements
- DOCSP ticket, API docs, etc
Follow Up Requirements
- additional tickets to file, required releases, etc
- if node behavior differs/will differ from other drivers, confirm with dbx devs what standard to aim for and what plan, if any, exists to reconcile the diverging behavior moving forward