PyTorch Inductor split-scan sizing bug can silently corrupt GPU memory

PyTorch's Inductor compiler can silently overrun GPU workspace memory when split-scan kernels are autotuned, producing nondeterministic NaNs and corrupted tensors without an obvious crash.

The flaw sits in how Inductor sizes the temporary workspace for split-scan. Allocation assumes the reduction block stays at or above Triton's minimum split-scan size (256 by default). Initial heuristic configs respect that floor, but coordinate-descent tuning is free to choose 128. The autotune cache then accepts the smaller block. More scan programs are launched than the workspace was built for, so they read and write past the end of the buffer.

A concrete example from the report: a workspace of 196608 bytes is allocated under the 256-block assumption, yet a 128-block launch needs 327680 bytes, an overrun of 128 KiB. The resulting corruption is silent and intermittent; it does not reliably trip ordinary error checks.

The reporter reproduced it with a standalone kernel that packs a NaN and ready-flag sentinel into a guard region, independent of any model or CUDA graphs. On an NVIDIA H100 and on an RTX 4050 laptop GPU, a 128-block configuration corrupted the guard on every trial and produced hundreds of thousands of NaN outputs; the same workspace with a 256-block configuration stayed clean.

Anyone running torch.compile under max-autotune on workloads that hit split-scan paths is exposed. Training runs can appear to succeed while silently poisoning gradients or activations, which is especially hard to debug when the failure only appears under certain tuned configurations.