Integer overflow in explodeForSort() allows crafted find(...).sort(...) query to crash MongoDB

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Critical - P2
    • None
    • Affects Version/s: 8.3.2
    • Component/s: None
    • None
    • Query Optimization
    • ALL
    • Hide

      1. Run a MongoDB Server instance with the affected code path.
      2. Ensure a compound index exists matching

      {f1:1, f2:1, f3:1, f4:1, f5:1, f6:1, f7:1, f8:1, sortField:1}

      .
      3. Send a normal find(...).sort(...) query with eight $in predicates, each containing 256 values.
      4. Observe planner math 256^8 = 2^64 wraps to 0 on 64-bit size_t.
      5. Observe the maxScansToExplode guard is bypassed and planning proceeds into Cartesian-product materialization.
      6. Observe client disconnect and server unavailability.

      Control

      • Repeat with 200 values per $in array.
      • Expected: queryPlanner.maxScansToExplodeReached=True and server remains healthy.

      Artifacts

      Show
      1. Run a MongoDB Server instance with the affected code path. 2. Ensure a compound index exists matching {f1:1, f2:1, f3:1, f4:1, f5:1, f6:1, f7:1, f8:1, sortField:1} . 3. Send a normal find(...).sort(...) query with eight $in predicates, each containing 256 values. 4. Observe planner math 256^8 = 2^64 wraps to 0 on 64-bit size_t. 5. Observe the maxScansToExplode guard is bypassed and planning proceeds into Cartesian-product materialization. 6. Observe client disconnect and server unavailability. Control Repeat with 200 values per $in array. Expected: queryPlanner.maxScansToExplodeReached=True and server remains healthy. Artifacts Report: https://gist.github.com/YLChen-007/af02589639a7ac411a549d6725281ebd
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Summary
      A denial-of-service vulnerability exists in MongoDB Server's query planner. A crafted find(...).sort(...) request with eight $in predicates of 256 values each can trigger a 64-bit integer overflow in QueryPlannerAnalysis::explodeForSort(). The overflow wraps the scan-count estimate to zero, bypasses the maxScansToExplode safety check, and lets the planner proceed into Cartesian-product materialization. In the verified end-to-end reproduction, the server becomes unavailable immediately after the public query is issued.

      Details

      • Vulnerable logic: src/mongo/db/query/planner_analysis.cpp inside QueryPlannerAnalysis::explodeForSort()
      • numScans *= oil.intervals.size() is unchecked
      • eight arrays of 256 values make 256^8 = 2^64, which wraps to 0 on 64-bit size_t
      • wrapped total bypasses getMaxScansToExplodeForOp() guard
      • execution continues into explodeNode() / makeCartesianProduct()

      Impact
      An authenticated client capable of issuing normal find() queries can crash or hang a mongod instance if the target collection has a matching compound index, or if the attacker can create one.

      Affected versions
      <= r8.3.2

      Severity
      High (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)

      Reference
      Private report gist: https://gist.github.com/YLChen-007/af02589639a7ac411a549d6725281ebd

            Assignee:
            Unassigned
            Reporter:
            芽 菜
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: