PyTorch Inductor CPU tiled reductions can overflow the heap
Full-width vector stores on tail blocks of 2D-tiled reductions corrupt memory or silently rewrite neighboring output rows.
PyTorch's Inductor backend for CPU can emit unsafe stores for 2D-tiled reductions when a non-reduction dimension is not a multiple of the vector width. Accumulation in the tail block is masked correctly, but the final write-back still issues a full-width vector store. That write runs past the end of the output buffer.
The failure shows up under torch.compile on ordinary fused graphs: pointwise work, pads, permutes, and a matmul whose shapes leave a short tail on the tiled axis. Eager execution is fine. Compiled runs either abort in the allocator with a glibc heap assertion or, when they do not crash, quietly overwrite values in the next output row. Contiguous layouts or simpler fusion patterns often dodge the path; channels-last inputs and multi-op fusion are enough to hit it.
For anyone relying on Inductor CPU kernels for correctness-sensitive work, the bug is serious: the same root cause yields both hard crashes and silent numerical corruption depending on buffer layout and neighboring allocations. The issue was reported against pytorch/pytorch with a minimal GELU-plus-pad-plus-matmul reproducer that fails consistently on a cold Inductor cache.