pytorch-jit-pt-oob-poc

PyTorch TorchScript .pt — two out-of-bounds read PoCs in torch.jit.load

Security-research proofs-of-concept for two distinct out-of-bounds reads reachable by loading a crafted TorchScript .pt model with torch.jit.load. Confirmed on torch 2.6.0 and present at pytorch HEAD 676ae52. CWE-125.

Building the malicious files from a clean scripted model:

python mk_pt.py        # writes clean.pt   (trivial scripted module)
python craft_pt.py     # -> evil_jit.pt     (finding 1)
python mk_pt2.py       # writes clean2.pt  (module with a 16 MB buffer)
python craft_storage.py  # -> evil_storage.pt (finding 2)

Finding 1 — evil_jit.pt (source-range text_table_[i] OOB)

SourceRangeDeserializer::deserialize_source (torch/csrc/jit/serialization/source_range_serialization.cpp) bounds-checks fnameIndex but not the per-element indices of textIndex, both read from the .debug_pkl. evil_jit.pt sets one textIndex entry to 0x7fffffff.

import torch
m = torch.jit.load("evil_jit.pt")   # loads fine (source ranges are lazy)
print(m.code)                        # -> Segmentation fault (exit 139)
# also crashes on m.inlined_graph and torch.jit.save(m, ...)

Finding 2 — evil_storage.pt (storage size / record mismatch OOB)

The storage persistent_load branch (torch/csrc/jit/serialization/unpickler.cpp) computes nbytes = numel * itemsize from the file but never checks nbytes <= actual_record_size. evil_storage.pt truncates a tensor's storage record to 16 bytes while data.pkl still declares the full numel, so the at::Storage claims far more than its backing buffer.

import torch
m = torch.jit.load("evil_storage.pt")   # loads fine
print(m(torch.ones(1)))                  # forward reads the storage -> Segmentation fault (exit 139)

Reported via coordinated disclosure (huntr.com). Researcher: s1ko (github.com/s1ko).