ExportXMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 4.18.2
    • Affects Version/s: None
    • Component/s: Security
    • None
    • None
    • Python Drivers
    • Not Needed
    • None
    • None
    • None
    • None
    • None
    • None

      Detailed steps to reproduce the problem?

      Include full traceback, if possible

      Encoding a single document whose values' cumulative encoded size exceeds INT_MAX (about 2 GiB) overflows the running buffer position in buffer_assure_space (bson/buffer.c).
      The overflow guard new_size < buffer->position depends on signed-overflow wraparound, which is undefined behavior. Compilers in the LLVM family (clang, and clang-based toolchains such as zig cc and Intel ICX) optimize the check away, so memcpy writes past the end of the heap allocation instead of the intended ValueError being raised. gcc- and MSVC-built extensions keep the check and raise ValueError as designed.

      Present since bson/buffer.c was imported in PyMongo 1.9 (2010); the current guard was added in PYTHON-2188 (3.11.0) and is itself UB-dependent. Among shipped artifacts, only the conda-forge macOS package is built with an affected toolchain; all PyPI wheels are gcc- or MSVC-built and are not affected. Full analysis, the compiler matrix, and reproduction are tracked privately in SECBUG-4274.

      Definition of done: what must be done to consider the task complete?

      • buffer_assure_space and buffer_grow reject a cumulative size past INT32_MAX
        without relying on signed-overflow behavior, so the guard holds on every compiler and raises
        ValueError.
      • A regression test covers the cumulative-size-past-INT_MAX case.
      • The conda-forge macOS package is rebuilt from the fixed source.
      • Severity and disclosure tracked in SECBUG-4274.

      The exact Python version used, with patch level:

      $ python -c "import sys; print(sys.version)"

      Version-independent. Observed on CPython 3.13; the defect is in the C extension's arithmetic, not tied to a Python version.

      The exact version of PyMongo used, with patch level:

      $ python -c "import pymongo; print(pymongo.version); print(pymongo.has_c())"

      All released versions from 1.9 onward. Observed against 4.18.0.dev0 at commit 500e1d0c.
      Requires the C extension (pymongo.has_c() is True); the pure-Python fallback is not affected.

      Describe how MongoDB is set up. Local vs Hosted, version, topology, load balanced, etc.

      Not applicable. The defect is in client-side BSON encoding and triggers before anything is sent to a server.

      The operating system and version (e.g. Windows 7, OSX 10.8, ...)

      Build- and compiler-dependent rather than OS-dependent. The failure occurs on extensions built by an LLVM-family compiler without -fno-strict-overflow; the shipping instance is the conda-forge macOS package.

      Web framework or asynchronous network library used, if any, with version (e.g. Django 1.7, mod_wsgi 4.3.0, gevent 1.0.1, Tornado 4.0.2, ...)

      Not applicable.

      Security Vulnerabilities

      If you’ve identified a security vulnerability in a driver or any other MongoDB project, please report it according to the instructions here

      Tracked internally in SECBUG-4274 (Medium). Do not add exploit or reproduction detail to this ticket.

            Assignee:
            Steve Silvester
            Reporter:
            Steve Silvester
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: