ONNX: Null Pointer Dereference in ScanInferenceFunction Due to Missing Required Attribute

Summary

ONNX shape inference did not safely validate the required Scan num_scan_inputs attribute. Two malformed values could terminate or disrupt the process:

1. If the attribute was missing, ctx.getAttribute("num_scan_inputs") returned null and was dereferenced.
2. If the attribute was negative, conversion to size_t produced a very large value that reached a vector allocation and raised std::length_error.

The negative-value variant passed onnx.checker.check_model() before reaching shape inference.

Technical details

The vulnerable Scan inference implementations used the following pattern:

auto num_scan_inputs =
    narrow_cast<size_t>(ctx.getAttribute("num_scan_inputs")->i());

This code neither checked the returned pointer nor rejected a negative signed value before converting it to an unsigned size. The pattern was present in the current Scan inference function and the older opset 8 and 9 paths.

The fix uses the required-attribute helper and checked narrowing:

auto num_scan_inputs =
    narrow<size_t>(getRequiredAttributeInt(ctx, "num_scan_inputs"));

Impact

An application that performs shape inference on an untrusted model can be terminated or forced into an exceptional allocation path, causing denial of service. No confidentiality or integrity impact was demonstrated.

Affected versions

• Affected: ONNX 1.4.0 through 1.21.0
• Patched: ONNX 1.22.0

ONNX 1.4.0 is the first release containing the vulnerable Scan shape-inference implementation.

Remediation

Upgrade to ONNX 1.22.0 or later.

• Fix: onnx/onnx#7916
• Commit: dd6bc92ea

Both reported models were re-tested against the published ONNX 1.23.2 wheel and correctly raise InferenceError.

Severity

The vulnerable ONNX component processes the malicious model through a local library API or file boundary and is not itself bound to a network stack. Applications that expose ONNX model processing over a network should calculate an Environmental score with Modified Attack Vector set to Network.

The two triggers remain in one advisory because they affect the same required attribute, share the same unsafe conversion path and remediation, and were fixed in the same release.