Integer overflow in query planner explodeForSort() can trigger mongod denial of service

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: 8.2.6
    • Component/s: None
    • None
    • Query Optimization
    • ALL
    • Hide

      1. Start a MongoDB server running the affected code path.
      2. Create or use a collection with a compound index matching

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

      .
      3. Issue a normal find(...).sort(...) query with eight $in predicates, each containing 256 point values.
      4. Observe planner math wraps: 256^8 = 2^64 -> 0 on 64-bit size_t.
      5. Observe that the safety guard is bypassed and planning proceeds into Cartesian-product materialization.
      6. Result: client disconnects and mongod becomes unavailable.

      Control case

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

      Artifacts

      Show
      1. Start a MongoDB server running the affected code path. 2. Create or use a collection with a compound index matching {f1:1, f2:1, f3:1, f4:1, f5:1, f6:1, f7:1, f8:1, sortField:1} . 3. Issue a normal find(...).sort(...) query with eight $in predicates, each containing 256 point values. 4. Observe planner math wraps: 256^8 = 2^64 -> 0 on 64-bit size_t. 5. Observe that the safety guard is bypassed and planning proceeds into Cartesian-product materialization. 6. Result: client disconnects and mongod becomes unavailable. Control case Repeat with 200 values per $in array. Expected behavior: queryPlanner.maxScansToExplodeReached=True and server remains healthy. Artifacts Report: https://gist.github.com/YLChen-007/e2baaa02f631dafb4d5ad88bb03f1692
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Summary
      A denial-of-service vulnerability exists in MongoDB server's query planner. A client that can issue find(...).sort(...) queries against a collection with a suitable compound index can supply large $in arrays that cause QueryPlannerAnalysis::explodeForSort() to overflow its size_t scan-count estimate. The wrapped value bypasses the maxScansToExplode safety check, after which makeCartesianProduct() materializes an enormous Cartesian product and can drive mongod into resource exhaustion and service unavailability.

      Details

      • Vulnerable area: src/mongo/db/query/planner_analysis.cpp
      • explodeForSort() multiplies point-interval counts into numScans without overflow checks
      • totalNumScans is compared to the safety limit only after unchecked arithmetic
      • With eight $in predicates of 256 values each, 256^8 = 2^64 wraps to 0 on 64-bit size_t
      • Planning then proceeds into explodeNode() / makeCartesianProduct(), causing practical resource exhaustion

      Impact
      An authenticated client with query capability against a collection that has a suitable compound index can trigger unbounded resource consumption through a single crafted query shape. Observed result: service unavailability of mongod. Depending on memory limits, the effect may be process termination, OOM kill, or prolonged unresponsiveness.

      Evidence

      • Control case using 200 values per $in array correctly set queryPlanner.maxScansToExplodeReached=True and kept the service alive
      • Overflow-sized query caused connection drop, failed post-query TCP/ping checks, and container exit

      Affected versions
      <= 8.2.6

      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/e2baaa02f631dafb4d5ad88bb03f1692

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

              Created:
              Updated: