# GGUF Tensor Data Offset Aliasing — Model Integrity Attack

**Status:** Preparing for Huntr submission
**Package:** [`gguf`](https://pypi.org/project/gguf/) (PyPI) — official gguf-py from [ggml-org/llama.cpp](https://github.com/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:

```python
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.

```bash
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.