Problem

windows (x64-cpu-static) has been red on every PR: test-quantize-fns SEGFAULT and test-quantize-perf exit 0xc0000374 (STATUS_HEAP_CORRUPTION). Linux legs passed silently.

Root cause

turboq_rotate_block_forward/_inverse loop to QK_K (256) but all four callers (tbq3_0/tbq4_0 quantize + dequantize) pass TBQ_BLK_SIZE (128) float buffers. Every call read and wrote 128 floats (512 bytes) past both scratch buffers. The Windows CRT heap checker trips on it; glibc doesn't, which is why Linux CI stayed green.

ASAN confirms pre-fix:

ERROR: AddressSanitizer: heap-buffer-overflow ... READ of size 4
  #0 matvec_row ggml-turboq.c:260
  #1 turboq_rotate_block_forward ggml-turboq.c:379
  #2 quantize_row_tbq3_0_ref ggml-turboq.c:476
0x... is located 0 bytes after 512-byte region (turboq_get_scratch)

Fix

Loop bound → TBQ_BLK_SIZE. Zero behavior change for the valid region — the second iteration only produced out-of-bounds garbage (the rotation tiles in TURBOQ_KV_DIM=128 chunks, so the first iteration fully covers the block). May also be implicated in the broken TBQ KV-cache on CPU (ggml-org#125) — heap corruption next to every dequant call is a plausible mechanism; not yet validated.

Validation

• test-quantize-fns + test-quantize-perf: pass under ASAN+UBSAN (RelWithDebInfo, sm-agnostic CPU path) — pre-fix, fns aborts with the trace above.
• RMSE checks in test-quantize-fns unchanged (tbq3_0/tbq4_0/q1_0 all pass).
• This PR's own CI run is the Windows proof.