You can deploy this model and start earning money today!

tonydav41/
armnn-poc-tensorinfo-dimspecificity-oob-2026-05-12

Name: armnn-poc-tensorinfo-dimspecificity-oob-2026-05-12
Availability: InStock

Views

No views yet

Arm NN Flatbuffers `.armnn` `dimensionSpecificity` Length Mismatch OOB PoC

PoC for huntr submission against Arm NN Flatbuffers – Arm.

Vulnerability

armnnDeserializer::ToTensorInfo() trusts the FlatBuffer dimensionSpecificity vector length without verifying it matches the dimensions vector length or that it stays within armnn::MaxNumOfTensorDimensions (5). FlatBuffer verification (VerifySerializedGraphBuffer) accepts mismatched vector lengths because each vector is individually well-formed. The deserializer then:

Overwrites the local size variable with dimensionSpecificity->size()
Copies that many bool values into a fixed five-element stack array (stack OOB write if size > 5)
Constructs TensorShape(size, outputDims.data(), dimensionsSpecificity) using the inflated size against outputDims.data() whose actual length is dimensions->size() — heap OOB read

Two verified variants:

Heap OOB read: 1 dimensions entry, 5 dimensionSpecificity entries → TensorShape reads beyond outputDims
Stack OOB write: 1 dimensions entry, 6 dimensionSpecificity entries → bool-array stack overflow

Both reproduced under AddressSanitizer with the canonical FlatBuffer verifier in the loop.

Affected version

Repo: https://github.com/ARM-software/armnn
Commit: f8beb5a9d50451dd06c804d6f7bbf8832f958125 (v26.01 release, "Update README for v26.01 Release (#818)")
Vulnerable code: src/armnnDeserializer/Deserializer.cpp L743-L760

CWE / CVSS

CWE-787 Out-of-bounds Write (stack-array overflow variant)
CWE-125 Out-of-bounds Read (heap variant via TensorShape construction)
CVSS 3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H = ~7.1 (local-vector downgrade to ~5.5 if huntr scores as local file open)
ML multiplier eligible — payload is a valid Arm NN Flatbuffers model file by the project's own schema.

Sinks

src/armnnDeserializer/Deserializer.cpp:

L743-L745: outputDims sized from dimensions->size()
L750-L756: size overwritten with dimensionSpecificity->size(); bools copied into fixed bool dimensionsSpecificity[5] stack array — no upper bound check
L759-L760: TensorShape(size, outputDims.data(), dimensionsSpecificity) — uses inflated size against outputDims of smaller length

Permalinks:

Reproducer

# Generate the malicious .armnn FlatBuffers
flatc -b -o tensorinfo-dimspecificity-oob \
  ArmnnSchema.fbs \
  bad-dimension-specificity.json
flatc -b -o tensorinfo-dimspecificity-oob \
  ArmnnSchema.fbs \
  bad-dimension-specificity-6.json

# Build the ASan harness against Arm NN's real TensorShape
c++ -std=c++17 -O1 -g -fsanitize=address \
  -I<armnn-include> -I<armnn-src> -I<flatbuffers-include> \
  repro.cpp \
  <armnn-src>/Tensor.cpp \
  <armnn-src>/Exceptions.cpp \
  -o repro

# Run against either malicious file
./repro bad-dimension-specificity.armnn       # heap OOB read
./repro bad-dimension-specificity-6.armnn     # stack OOB write

Both files pass VerifySerializedGraphBuffer — the verifier does NOT catch the cross-vector length mismatch. The ASan trace in asan-output.txt shows the exact failure mode.

Files

bad-dimension-specificity.armnn — heap OOB variant (236 B)
bad-dimension-specificity.json — JSON source for the heap variant
bad-dimension-specificity-6.armnn — stack OOB variant (236 B)
bad-dimension-specificity-6.json — JSON source for the stack variant
repro.cpp — ASan harness that runs VerifySerializedGraphBuffer then the vulnerable ToTensorInfo logic
asan-output.txt — captured ASan trace
poc-README.md — auditor's notes from /tmp/armnn-audit/poc/

Impact

Any process or service that calls Arm NN's armnnDeserializer::Deserializer::ReadGraph() (or higher-level wrappers like armnn::INetworkPtr deserializer->CreateNetworkFromBinary(...)) on a user-supplied .armnn file:

Heap OOB read leaks memory (no direct disclosure proof in PoC, but the primitive is there)
Stack OOB write corrupts adjacent stack frame metadata — process crash deterministically, potential code-execution primitive depending on stack layout
Both happen during model load, before any inference — no inputs required

Surfaces affected: Arm NN's reference runtime, any embedded inference SDK that vendors Arm NN (Arm's own NN SDK ships in Mali GPU drivers, mobile inference apps, IoT inference frameworks).

Distinguisher

FlatBuffer schema doesn't mark dimensionSpecificity length as constrained against dimensions length, so VerifySerializedGraphBuffer accepts it
The bug is the runtime's assumption that the two vectors have matching length, not a verifier bug
No prior CVE, GHSA, or huntr disclosure for this code path
Distinct from any generic FlatBuffer parser issue — this is Arm-NN-specific semantic validation

Recommended fix

Add semantic validation in ToTensorInfo() before consuming dimensionSpecificity:

cpp

if (dimensionSpecificity != nullptr) {
    if (dimensionSpecificity->size() != dimensions->size()) {
        throw ParseException("dimensionSpecificity length must equal dimensions length");
    }
    if (dimensionSpecificity->size() > armnn::MaxNumOfTensorDimensions) {
        throw ParseException("dimensionSpecificity exceeds MaxNumOfTensorDimensions");
    }
    // ... existing copy loop ...
}

Defense in depth: extend the schema to add (required) annotation on the constraint, or add a validate_program()-style walker that checks all per-tensor invariants after VerifySerializedGraphBuffer succeeds.

Reporter

Reported by lendtrain (huntr) / tonydav41 (HuggingFace). Filed 2026-05-12.

tonydav41/armnn-poc-tensorinfo-dimspecificity-oob-2026-05-12

Arm NN Flatbuffers .armnn dimensionSpecificity Length Mismatch OOB PoC