[SERVER-32191] DocumentSourceSkip can overflow a long long when combining with adjacent skips Created: 06/Dec/17  Updated: 30/Oct/23  Resolved: 19/Mar/18

Status: Closed
Project: Core Server
Component/s: Aggregation Framework
Affects Version/s: 3.4.10, 3.6.0
Fix Version/s: 3.7.4

Type: Bug Priority: Major - P3
Reporter: Kyle Suarez Assignee: Charlie Swanson
Resolution: Fixed Votes: 0
Labels: bkp, neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.6, v3.4
Participants:

 Description   

During optimization, $skip will combine itself with an adjacent $skip, and the new value to skip is the sum of the two. However, the addition is performed without overflow checking. The skip value is stored as a long long, which means that we hit undefined behavior in the event of overflow.

The unsafe code is in DocumentSourceSkip::doOptimizeAt() in v3.6 and v3.4.



 Comments   
Comment by Githook User [ 19/Mar/18 ]

Author:

{'email': 'KevinCybura@gmail.com', 'name': 'KevinCybura', 'username': 'KevinCybura'}

Message: SERVER-32191 Prevent overflow during optimization of $skip.

Closes #1225

Signed-off-by: Charlie Swanson <charlie.swanson@mongodb.com>
Branch: master
https://github.com/mongodb/mongo/commit/581b7d49ccbe2ec575c615c2d6daa5c42e94b4c7

Comment by Charlie Swanson [ 16/Mar/18 ]

Assigning to myself since there is a pull request from one of the CUNY students I'm working with.

Comment by Kyle Suarez [ 06/Dec/17 ]

asya – yes, sorry, I meant doOptimizeAt(). Updating the description.

In the code on master we will swap with a limit but the risk of overflow remains. See https://github.com/mongodb/mongo/blob/6409e02490d57ae2191bb3960fec8f6ca09fc5b4/src/mongo/db/pipeline/document_source_skip.cpp#L89-L99

Comment by Asya Kamsky [ 06/Dec/17 ]

do you mean DocumentSourceSkip::doOptimizeAt? Does the same issue apply to adding skip and limit there?

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