A Segmentation Fault can be trigerred in torch.clone

[shijy16]

🐛 Describe the bug

A Segment Fault can be triggered in torch.clone by giving a tensor with a shape containing both large values and 0.

The PoC:

import torch
input = torch.rand([0, 2**20, 4001423662007321682], dtype=torch.float32)
res = torch.clone(
    input=input,
)

The output:

Segmentation fault (core dumped)

Versions

Collecting environment information...
PyTorch version: 1.13.1+cu117
Is debug build: False
CUDA used to build PyTorch: 11.7
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.5 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu120.04.1) 9.4.0
Clang version: 11.0.0-2ubuntu20.04.1
CMake version: version 3.16.3
Libc version: glibc-2.31

Python version: 3.10.6 (main, Oct 24 2022, 16:07:47) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.15.0-57-generic-x86_64-with-glibc2.31
Is CUDA available: True
CUDA runtime version: 11.8.89
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: GPU 0: Tesla V100-PCIE-16GB
Nvidia driver version: 520.61.05
cuDNN version: Probably one of the following:
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn.so.8.1.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.1.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.1.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.1.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.1.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.1.1
/usr/local/cuda-11.0/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.1.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn.so.8.2.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.2.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.2.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.2.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.2.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.2.1
/usr/local/cuda-11.2/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.2.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 46 bits physical, 48 bits virtual
CPU(s): 48
On-line CPU(s) list: 0-47
Thread(s) per core: 2
Core(s) per socket: 12
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Silver 4214 CPU @ 2.20GHz
Stepping: 7
CPU MHz: 2200.000
BogoMIPS: 4400.00
Virtualization: VT-x
L1d cache: 768 KiB
L1i cache: 768 KiB
L2 cache: 24 MiB
L3 cache: 33 MiB
NUMA node0 CPU(s): 0-11,24-35
NUMA node1 CPU(s): 12-23,36-47
Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Mitigation; Clear CPU buffers; SMT vulnerable
Vulnerability Retbleed: Mitigation; Enhanced IBRS
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Enhanced IBRS, IBPB conditional, RSB filling, PBRSB-eIBRS SW sequence
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Mitigation; TSX disabled
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single intel_ppin ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts hwp_epp pku ospke avx512_vnni md_clear flush_l1d arch_capabilities

Versions of relevant libraries:
[pip3] numpy==1.23.4
[pip3] torch==1.13.1
[conda] numpy 1.23.4 pypi_0 pypi
[conda] torch 1.13.1 pypi_0 pypi

cc @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10

[malfet]

@jingxu10 I've removed module: cpu as this crash is not specific to CPU.
Also, please note, that in latest nightly it raises a bit confusing, but a segmented exception:

>>> import torch
>>> input = torch.rand([0, 2**20, 4001423662007321682], dtype=torch.float32)
>>> torch.clone(input)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: /home/nshulga/git/pytorch/pytorch/build/aten/src/ATen/RegisterCPU.cpp:5146: SymIntArrayRef expected to contain only concrete integers

[jingxu10]

@malfet got it. Thanks you.

[CaoE]

@shijy16 It is because the input size of dim1 and size of dim2 are large and the stride for dim0 overflows, which make stride of dim0 not a concrete integer using Symint.

input = torch.rand([0, 2**20, 8796093022207], dtype=torch.float32)

Use the input above instead and it will work fine in latest nightly because 2**20 * 8796093022207 can be represented by int64.

[shijy16]

@shijy16 It is because the input size of dim1 and size of dim2 are large and the stride for dim0 overflows, which make stride of dim0 not a concrete integer using Symint.

input = torch.rand([0, 2**20, 8796093022207], dtype=torch.float32)

Use the input above instead and it will work fine in latest nightly because 2**20 * 8796093022207 can be represented by int64.

Thank you for your response!
I think an exception with concret error message should be raised when an overflow input is given.
A segment fault should not occur anyway .

[CaoE]

I think an exception with concret error message should be raised when an overflow input is given. A segment fault should not occur anywayalways be .

Yes, pytorch might also check the overflow for stride when create a tensor. Considering this case, may we need to add overflow check for int64 and add check for the overflow of calculating of strides ? @peterbell10

[peterbell10]

Adding an overflow check seems reasonable. There is already safe_compute_numel which catches overflows the non-empty case.

[CaoE]

@peterbell10 safe_compute_numel catches overflows for non-empty case, but it is hard to be used directly for empty case because the numel is zero and each multiplication may not overflow uint64 but overflow int64 during the computation of safe_compute_numel. We need check for stride calculation e.g. #94900 (just a idea check)