Bump OpenCTM to fix heap overflows on crafted .ctm files (S9S disclosure) - #6800
Merged
Conversation
Points the OpenCTM submodule and the vcpkg overlay port at the fix for a heap-buffer-overflow write reachable from ctmLoad on a crafted .ctm file (32-bit len+1 wrap in _ctmStreamReadSTRING). MeshInspector/OpenCTM#2. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…ader, stop parsing after a failure
…e, vcpkg port and CPM lock
Fedr
marked this pull request as ready for review
September 8, 2026 09:38
Grantim
approved these changes
Sep 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Bumps our OpenCTM dependency to the two fixes from the S9S Security Research coordinated disclosure, both reachable from
ctmLoad()on a single crafted.ctmfile and therefore from our ownfromCtmload path (source/MRIOExtras/MRCtm.cpp), since the defects are in the library's allocation code, not in the read callback:_ctmStreamReadSTRING:malloc(len + 1)wraps forlen = 0xFFFFFFFF, then up tolenattacker bytes are read into a ~0-byte buffer (CWE-190 → CWE-787).mallocdirectly, socount * stridewrapped to an undersized buffer on 32-bitsize_t(our wasm32 build) and in the 32-bitCTMuintproducts of the float-map andstream.ctemp buffers. Counts aboveUINT_MAX / 16are now rejected withCTM_BAD_FORMAT. Also frees a leaked MG1 temp buffer on a failed read.Pinned to OpenCTM
masterat eae87a4d9ac229bdc7c32492c84bd7cb1329e5c4, the squash-merge of MeshInspector/OpenCTM#3 on top of MeshInspector/OpenCTM#2.Changes
OpenCTM reaches the build three different ways, so all three pins move together:
thirdparty/OpenCTM-gitsubmodule (Linux dockers, macOS, emscripten) → eae87a4d9.thirdparty/vcpkg/ports/openctmoverlay port (Windows,rockylinux8-vcpkgincl. manylinux wheels):REF+SHA512→ eae87a4d9's archive,port-version3 → 4 (forces a rebuild of the cached binary).thirdparty/cpm/package-lock.cmake(CPM build from Add option to build third-party dependencies without submodules #6775)GIT_TAG→ eae87a4d9.thirdparty/licenses/manifest.jsonre-pinned viacheck_third_party_licenses.py --update-versions.Verification (in the OpenCTM PRs)
MeshInspector/OpenCTM#2: ASan build via the public
ctmLoad()on the 44-byte reproducer: overflow before, clean rejection after; a valid mesh with a file comment still round-trips.MeshInspector/OpenCTM#3: i686 (32-bit
size_t) and x86-64 builds: a RAW file declaring0x15555556vertices segfaulted before and is rejected withCTM_BAD_FORMATafter; a valid RAW mesh still loads on both.