Circle (Samsung/ONE) unchecked buffer index heap OOB read PoC (source-verified)
Proof-of-concept material for a huntr Model Format Vulnerability report
against Samsung/ONE (circle-mlir,
circle-mlir/circle-mlir/lib/import/src/CircleImport.cpp:875,956).
The bug, verified against the live source fetched directly today
Tensor.buffer (schema circle_schema.fbs) is a plain uint (0..2^32-1)
serving as an index into the root buffers:[Buffer] FlatBuffers vector,
with no upper bound encoded in the schema itself. The import code does:
buffer = buffers[const_tensor.buffer]->data; // lines 875 and 956, current source
operator[] performs no range check. There is no const_tensor.buffer < buffers.size() check anywhere between reading the value from the file and
this dereference. The only structural defense, circle::VerifyModelBuffer()
(the FlatBuffers verifier), checks offset validity, not this kind of
semantic cross-reference (by design, FlatBuffers verifiers cannot validate
"this scalar field must index into that other vector") - and it is skipped
entirely for models >= 2GB (CircleImport.cpp:~1000).
repro.cpp reproduces the exact indexing arithmetic in isolation:
real buffers.size() = 5
attacker-controlled index = 4294967295
computed address = base + 4294967295 * 8 bytes = base + 32.00 GiB past the real allocation
Reachable via the public circle-impexp CLI tool
(driver.cpp -> circleimpexp.cpp -> FlatBufferToMlir -> ConvertSubgraph)
- a real, documented entry point that takes a file path from argv directly.
Honest limits, and an important note on provenance (not swept under the rug)
The exact same pattern (buffers[const_tensor.buffer]) exists verbatim in
current tensorflow/tensorflow (this file carries a header comment "from
tensorflow/compiler/mlir/lite/flatbuffer_import.cc") - TensorFlow's own
SECURITY.md explicitly states "using untrusted models or graphs is
equivalent to running untrusted code" and does not treat this class as a
vulnerability there. Samsung/ONE is a SEPARATE repository with no equivalent
SECURITY.md exclusion, and has accepted memory-safety reports before (e.g.
issue #13348, "Heap Buffer Overflow in JpegHelper::readJpeg") - so this is
not a vendor-excluded target, but whether an upstream-inherited pattern
counts as a valid finding for the downstream repository is a judgment call
for the triager, disclosed here plainly rather than presented as an
unambiguous first-party bug.
No PoC .circle file / compiled circle-impexp binary was built or run in this report - circle-mlir is a large LLVM/MLIR-based compiler toolchain, and a full build was judged out of reasonable scope for this report. Confidence rests on direct reading of the current live source and isolated reproduction of the exact indexing arithmetic, not on a live crash.
Impact: heap out-of-bounds read (a more severe class than pure DoS) via a
crafted .circle model file with an out-of-range Tensor.buffer index -
likely segfault/crash, and in principle a basis for info leak given
favorable heap layout.
Suggested fix: Validate const_tensor.buffer < buffers.size() before the
dereference at both call sites, and do not skip this check for models >= 2GB.