| --- |
| license: apache-2.0 |
| --- |
| |
| # Tensorizer `.tensors` dtype-validation PoC (huntr responsible disclosure) |
|
|
| This repository contains a **proof-of-concept model file** for a responsible |
| security disclosure submitted to [huntr](https://huntr.com) regarding |
| [coreweave/tensorizer](https://github.com/coreweave/tensorizer). |
|
|
| Access is **gated with manual review** so the crafted file is not freely |
| downloadable. It is shared with `protectai-bot` for huntr triage. |
|
|
| ## What this is |
|
|
| `malicious_tensor.tensors` (222 bytes) is a minimal, hand-constructed |
| Tensorizer file whose tensor header declares `dtype="O"` (numpy object |
| dtype). Every other byte is produced by Tensorizer's own serialization |
| classes, so the file is structurally legitimate. |
|
|
| Loading it causes Tensorizer to construct a numpy **object-dtype array over |
| raw file bytes**, meaning attacker-controlled bytes are treated as |
| `PyObject*` pointers. `numpy.frombuffer` refuses this exact operation by |
| design; Tensorizer reaches around that guard via the low-level |
| `numpy.ndarray.__new__` path. |
|
|
| ## Scope of the claim |
|
|
| This is reported as a **latent memory-safety / defense-in-depth defect, not |
| a working RCE.** All public deserialization paths currently funnel through |
| `to_tensor()` → `torch.from_numpy()`, which rejects object dtype before the |
| array reaches a caller. That containment is incidental (it lives in PyTorch, |
| not Tensorizer) rather than a designed validation step. |
|
|
| The constructed array is nonetheless genuinely unsafe: accessing an element |
| of it segfaults (SIGSEGV), demonstrated in `verify_gc_claim.py`. |
|
|
| ## Files |
|
|
| | File | Purpose | |
| | --- | --- | |
| | `malicious_tensor.tensors` | The 222-byte PoC file | |
| | `build_tensorizer_poc.py` | Builds the PoC from scratch; `--load` runs it in a resource-bounded subprocess | |
| | `verify_gc_claim.py` | Three-stage isolated-subprocess probe (metadata / GC / element access) that produced the SIGSEGV evidence | |
|
|
| ## Safety |
|
|
| The payload is a repeating `0x41` pattern — a non-canonical, unmapped |
| address, chosen so that a genuine dereference **faults** rather than |
| corrupting anything real. The file performs no I/O, spawns nothing, and |
| contains no executable payload. It is a crash-reproduction artifact. |
|
|
