onnx-reference-evaluator-shape-bomb-poc

ONNX ReferenceEvaluator — Unbounded Shape/Count Memory & Resource Exhaustion (4 operators)

Status: Preparing for Huntr submission Package: onnx (PyPI) — official Linux Foundation / Microsoft package, onnx.reference.ReferenceEvaluator Affected files: onnx/reference/ops/op_constant_of_shape.py, op_tile.py, op_expand.py, op_range.py Class: CWE-789 (Convergent Untrusted-Length Allocation) / CWE-400 (Uncontrolled Resource Consumption), root cause CWE-20 (Improper Input Validation) Severity: High — models under 220 bytes cause multi-gigabyte memory consumption, either silently succeeding or crashing the process, with no validation opportunity for the caller.

Summary

onnx.reference.ReferenceEvaluator is the pure-Python reference implementation shipped inside the main onnx package (distinct from the separate, compiled onnxruntime engine) — used for testing, CI validation, spec-compliance checking, and lightweight inference without a full runtime.

Four of its operator kernels take a shape / repeat-count / range-length value directly from a graph tensor — in practice, an ordinary tiny Constant node embedded in the model file — and pass it straight into a numpy allocation call with no upper-bound validation:

In every case the declaring value is a handful of bytes (a single int64), while the resulting allocation can be gigabytes. None of the four check the requested element count against any bound before calling into numpy.

Proof of Concept

poc_onnx_reference_evaluator_bomb.py builds four minimal, fully valid ONNX models with onnx.helper (no hand-crafted binary patching needed — the vulnerable value is just an ordinary small Constant node) and runs each through ReferenceEvaluator in a subprocess, measuring peak RSS / outcome.

pip install onnx numpy
python poc_onnx_reference_evaluator_bomb.py

Measured results

All four models declare 500,000,000 elements.

Two of the four (ConstantOfShape, Tile) return "successfully" with a valid-looking large array and zero error signal — the caller has no way to detect anything went wrong short of monitoring process memory externally. The other two (Expand, Range) crash the process outright. Either way, a file under 220 bytes controls the outcome.

Impact

Any code path that loads and evaluates an untrusted ONNX file through ReferenceEvaluator — CI test harnesses that run community-submitted models, model validation/preview services, lightweight pure-Python inference without onnxruntime — can be forced into multi-gigabyte memory consumption or an outright crash by a file of a few hundred bytes, with the model appearing completely ordinary (it's a normal Constant → operator graph, not a malformed file).

Suggested fix

Before allocating in each of the four kernels, validate the requested element count (product of shape dims for ConstantOfShape/Expand, size(x) × prod(repeats) for Tile, (end - start) / step for Range) against a configurable sane maximum, and raise a clear error immediately instead of proceeding to allocate.

Relationship to prior findings

This is the same broad class (CWE-789, CULA) previously confirmed in numpy, joblib, zarr, hickle, skops, anndata, fastparquet, and keras+h5py — but this is the first instance found in ONNX's own reference evaluator, and it's systemic across four separate operator implementations rather than a single code path, discovered by pattern-matching the first confirmed instance (ConstantOfShape) against sibling operators known to have similar historical issues elsewhere in the ONNX ecosystem.

Disclosure

Please do not use this PoC against production systems you do not own or have explicit permission to test.