sr64/poc-pytorch-flatbuffer-storage-offset-cwe125

PoC: OOB via unchecked storage_offset in PyTorch mobile flatbuffer loader (CWE-125/787)

Loading a crafted PyTorch Mobile flatbuffer model (.ptl) sets a tensor's storage_offset (and sizes/strides) directly from attacker bytes with no bounds check, so later tensor access is out of bounds.

Root cause (guarded-vs-unguarded asymmetry)

torch/csrc/jit/mobile/flatbuffer_loader.cpp:

impl->set_storage_offset(tensor_md->storage_offset());   // L515: raw flatbuffer field, NO bounds check
impl->set_sizes_and_strides(size, stride);               // L521: raw flatbuffer sizes/strides

The pickle path (unpickler.cpp:1000-1041) guards the offset with THREE checks: storage_offset >= 0, offset_nbytes <= storage_nbytes, and computeStorageNbytes(size,stride,itemsize,offset) <= storage_nbytes. The flatbuffer path applies none of them. TensorImpl::set_storage_offset() itself documents "WARNING: This does NOT check if the tensor is in bounds." A crafted .ptl flatbuffer whose storage_offset/sizes/strides exceed the backing storage makes any later element access compute a data pointer outside the storage allocation → OOB read/write. Reachable via torch::jit::_load_for_mobile() (no trust opt-in).

Reproduce (AddressSanitizer)

g++ -fsanitize=address -g -O0 pytorch_flatbuffer_storage_offset_harness.cpp -o poc && ./poc
# storage has 4 floats; flatbuffer storage_offset=64, numel=8 (no bounds check)
# ==ERROR: AddressSanitizer: heap-buffer-overflow  READ of size 4 ... 240 bytes after the 16-byte storage

storage_offset is an int32 field, so an attacker can point the data pointer far outside the storage.

Fix

Apply the same bounds checks the pickle path uses (offset >= 0; offset + computeStorageNbytes(size,stride) <= storage size) in the flatbuffer loader before set_storage_offset/set_sizes_and_strides.