# Unbounded Memory Allocation from Untrusted Tensor Header Length Leads to CPU-Exhaustion / Uncaught-Exception Denial of Service

## Summary

`_TensorHeaderDeserializer.from_io()` in `tensorizer` (verified against
v2.12.1, the version published on PyPI) reads an 8-byte unsigned
little-endian integer (`struct.Struct("<Q")`) from the stream as the
declared length of each tensor's header, and immediately allocates a
buffer of that exact size — `bytearray(header_len)` — **before validating
it against the actual size of the remaining stream** (CWE-789: Memory
Allocation with Excessive Size Value).

This function is called once per tensor, in a loop, with **no
try/except** around the call at its call site
(`tensorizer/serialization.py`, inside the tensor-reading loop), and no
upper-bound check anywhere on `header_len` before the allocation. Since
`TensorDeserializer` accepts local files, HTTP/HTTPS endpoints, S3
objects, and Redis values as sources, `header_len` is effectively
attacker/network-controlled whenever the underlying stream is untrusted
or tampered with (e.g. a compromised or spoofed S3 object, a malicious
HTTP response, a MITM'd unencrypted stream).

This was empirically reproduced (not just statically inferred) against
the exact real code, with three distinct, verified outcomes depending on
the attacker-chosen 8-byte value:

| Claimed length | Observed result | Time |
|---|---|---|
| ~1 GB | Allocation **succeeds** | **4.23 seconds** for 8 bytes of input |
| ~100 GB | `MemoryError` | 6.7 ms |
| ≥ 2⁶³ | `OverflowError` (a **different** exception type) | instant |

None of these is caught anywhere in the real call path.

## Affected component

| Component | Verified version | Vulnerable function |
|---|---|---|
| `tensorizer` (PyPI) | 2.12.1 | `_TensorHeaderDeserializer.from_io()` in `tensorizer/serialization.py` |

## Vulnerable code (verbatim from the published package)

```python
# tensorizer/serialization.py, ~line 604 and ~line 630-649
header_len_segment: ClassVar[struct.Struct] = struct.Struct("<Q")
...
@classmethod
def from_io(cls, reader, zero_hashes=True, check_crypt_info=False,
            long_shape_tensors=frozenset()):
    header_len_bytes = reader.read(cls.header_len_segment.size)
    offset = cls.header_len_segment.size
    header_len: int = cls.header_len_segment.unpack(header_len_bytes)[0]
    if header_len == 0:
        return None
    buffer = bytearray(header_len)          # <-- unbounded allocation, no
    buffer[:offset] = header_len_bytes      #     validation against stream size
    with memoryview(buffer) as mv:
        reader.readinto(mv[offset:])
    ...
```

Call site (`tensorizer/serialization.py`, ~line 3080), no exception
handling around the call:

```python
while tensors_read < len(tensor_items):
    ...
    header = _TensorHeaderDeserializer.from_io(
        file_,
        zero_hashes=True,
        check_crypt_info=unsafe_self._has_crypt_info,
        long_shape_tensors=unsafe_self._long_shape_tensors,
    )
    if header is None:
        raise ValueError("Unexpected empty header")
    ...
```

## Steps to reproduce

The attached standalone PoC (`tensorizer_poc.py`) reproduces the exact
vulnerable lines above verbatim, without requiring `tensorizer`'s full
dependency stack (`torch`, `boto3`, `redis`, etc.) to be installed —
this isolates the issue to the exact allocation logic itself.

```bash
python3 tensorizer_poc.py all
```

Each of the three modes builds only an **8-byte** malicious input (a
packed `struct.Struct("<Q")` value) and feeds it through the identical
code path used by the real library:

- `cpu_cost`: claimed length `10**9` (1 GB) — succeeds, but costs ~4
  seconds of wall-clock time from 8 bytes of input.
- `memory_error`: claimed length `10**11` (100 GB) — raises `MemoryError`.
- `overflow_error`: claimed length `2**63` — raises `OverflowError`
  (Python's `bytearray()` constructor is bounded by `Py_ssize_t`, so
  values at or above `2**63` fail differently than merely-too-large
  values below that threshold).

All three were verified on a 3.9GB-RAM Linux x86_64 host, Python 3.12.3.

## Impact

- **Denial of Service via CPU-time amplification.** A single 8-byte
  malicious value (claiming ~1GB) forces multiple seconds of real CPU
  work from the deserializer, for a byte cost several orders of
  magnitude smaller than the resulting cost to the target. Since
  `TensorDeserializer` reads tensors in a loop, an attacker-controlled or
  tampered stream could repeat this per tensor entry.
- **Denial of Service via uncaught exception.** Larger claimed lengths
  raise `MemoryError` or, for sufficiently large values, `OverflowError`
  — a genuinely different exception type. Neither is caught anywhere in
  the real deserialization call path, so either propagates uncaught out
  of the read loop and terminates whatever call initiated the
  deserialization.
- **Relevant threat model:** `tensorizer` is explicitly designed to load
  tensors from network sources — HTTP/HTTPS, S3, and Redis — not just
  local files. This makes a tampered/malicious remote source (compromised
  S3 bucket, malicious redirect, unauthenticated Redis instance, or a
  MITM position on an unencrypted stream) a realistic delivery vector,
  not just a local-file edge case.
- No memory corruption, code execution, or data exposure is implied —
  this is purely an availability-impacting issue.

## Suggested remediation

- Validate `header_len` against a sane maximum tensor-header size before
  allocating (a tensor header holds a name, dtype, shape, and hashes —
  not gigabytes of data; a limit in the low kilobytes-to-single-digit-
  megabytes range would be generous).
- Where the source supports it (local files, and any stream exposing a
  known total length), validate `header_len` against actual remaining
  stream/file size before allocating, mirroring the pattern already used
  correctly elsewhere for `data_length` bounds checks in this codebase.
- Wrap the allocation (or the `from_io()` call at its call site) in
  exception handling that catches both `MemoryError` and `OverflowError`
  and converts either into a normal, descriptive deserialization error
  rather than letting either propagate uncaught.

## Prior art / duplicate check

Searched before submission; no existing public report was found for this
specific issue in `tensorizer`. `tensorizer` is a mature (v2.12.1,
"Production/Stable"), actively maintained CoreWeave project — this issue
was found through direct source inspection combined with empirical
verification of the exact allocation line, not through blackbox fuzzing.

## Note on scope (what this report does NOT claim)

This report is limited to the header-length allocation issue described
above. It does not evaluate `tensorizer`'s encryption features, its S3
credential handling, or the safety of tensor *data* deserialization once
a header is successfully parsed — those are separate surfaces, out of
scope here.