PyTorch from_file builds oversized tensors after byte-count overflow

PyTorch's torch.from_file can return a tensor whose reported element count far exceeds the file-backed storage underneath it when the requested size overflows the internal byte calculation.

The constructor takes an element count and dtype, multiplies them to decide how many bytes to map, and on overflow wraps that product. Callers then get a tensor whose numel() claims a huge logical range while the untyped storage remains only as large as the real file. Index zero may still read; later indices inside the advertised range hit storage-bounds errors. The same oversized count is rejected outright when allocated on the meta device.

The mismatch showed up on multiple PyTorch releases across CPU Linux and Windows builds and on Linux CUDA hosts using CPU tensors. It does not need a large allocation or a large file: an eight-byte file plus a wrapped float64 count is enough. Equivalent behavior appeared with several numeric and complex dtypes.

In practice this means code that trusts numel() or slices within the reported range can trip unexpected bounds failures, or worse, operate under false assumptions about how much storage is actually mapped. The expected fix is to refuse the overflow with a catchable error before any tensor is returned, matching the meta path.