MBM7/gguf-tensor-offset-aliasing-poc

GGUF Tensor Data Offset Aliasing — Model Integrity Attack

Status: Preparing for Huntr submission Package: gguf (PyPI) — official gguf-py from ggml-org/llama.cpp File / function: gguf/gguf_reader.py, GGUFReader._build_tensors() Class: CWE-1284 / CWE-20 (missing validation of a structural invariant) Severity: Medium-High — not a crash/DoS, but a silent model-integrity violation: a GGUF file can declare tensors that don't actually contain the data their name/shape/dtype claim.

Summary

Each tensor's absolute position in a GGUF file is computed as:

data_offs = int(start_offs + offset_tensor[0])

where offset_tensor is a per-tensor uint64 read directly from the tensor-info section, with no validation that different tensors' offsets are unique or non-overlapping.

Tensor names are checked for duplicates (_build_tensors raises ValueError on a repeated name) — but nothing stops two tensors with different names, shapes, and/or dtypes from pointing at the exact same, or partially overlapping, bytes. The reader accepts this silently.

Proof of Concept

poc_gguf_tensor_offset_aliasing.py demonstrates two variants (it builds minimal, spec-correct GGUF files by hand, so it has no dependency on any particular writer library):

Variant 1 — full aliasing (identical shape/dtype)

Two tensors, blk.0.attn_q.weight = [1,2,3,4] and blk.0.attn_k.weight = [9.9,9.9,9.9,9.9], both float32. Patching only the 8-byte offset field of attn_k.weight to alias attn_q.weight's position:

attn_q.weight: offset=192 data=[1. 2. 3. 4.]
attn_k.weight: offset=192 data=[1. 2. 3. 4.]   <- should be [9.9, 9.9, 9.9, 9.9]

Both tensors report identical data. attn_k.weight's real declared data is silently unreachable — zero exception, zero warning.

Variant 2 — partial overlap, different shape and dtype

blk.0.big_weight (float32, 8 elements) and blk.0.small_meta (int32, 2 elements). Patching small_meta's offset to alias the first 8 bytes of big_weight:

big_weight (F32): [1.1 2.2 3.3 4.4 5.5 6.6 7.7 8.8]
small_meta (I32): [1066192077 1074580685]

1066192077 and 1074580685 are the exact IEEE-754 bit patterns of 1.1 and 2.2 reinterpreted as raw int32. A tensor of any declared shape and dtype can be carved out of any byte range in the file, regardless of what other tensor(s) claim that same range.

pip install gguf numpy
python poc_gguf_tensor_offset_aliasing.py

Impact

A GGUF file can declare many distinct-looking weight tensors — correct names, correct shapes, passes casual inspection — that actually all alias onto a small set of real bytes. This can be used to:

• Disguise a stripped-down, incomplete, or backdoored model as a full one (the file "looks complete" while being functionally near-empty of real trained data).
• Defeat any tool that hashes or verifies individual tensors under the assumption that each occupies distinct file bytes (two aliased tensors trivially produce identical hashes, which can be exploited to hide tampering from spot-check verification).
• Corrupt inference silently rather than failing loudly: a model could load "successfully" while actually running with garbage or duplicated weights in place of the tensors it claims to have.

What's correctly protected (included for completeness)

• Duplicate tensor names are rejected — confirmed via source: _build_tensors() raises ValueError('Found duplicated tensor with name ...').
• Aliasing cannot reach backward into the KV-metadata/header region — mathematically impossible, since offset_tensor is unsigned and added to start_offs (the data region's start); the minimum reachable position is start_offs itself.
• A single tensor whose declared offset+size exceeds the actual file size IS caught, via the reader's own reshape() validation (individual out-of-bounds tensors are not the gap here — cross-tensor uniqueness is).

Suggested fix

Track allocated byte ranges while building the tensor list in _build_tensors(), and raise a clear error if any two tensors' [data_offs, data_offs + n_bytes) ranges overlap.

Relationship to other reports

Distinct from the previously reported "KV Array Field Unbounded Length" finding in the same package (CWE-834/CWE-400, a resource-exhaustion issue) — this is a data-integrity issue (CWE-1284/CWE-20), closer in spirit to the numpy NPZ key-shadowing finding (CWE-706/CWE-345) reported separately, but via byte-offset overlap rather than string-key collision.

Disclosure

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