SORTu64's merge carves chunks of clen u64s and tries to clamp the trailing partial chunk, but the clamp targets the physical last array slot after the heap has reordered chunks by value, so the actual overrunning chunk survives unclamped and is later consumed, reading up to (clen-1)*8 bytes past the from/into buffer. The goal is to clamp each partial chunk at creation time, before it enters the heap.
Post-hoc clamp is applied to the wrong (heap-reordered) chunk.
abc/SORT.c:23-38 — loop does p += clen; chunk[1] = (u8c*)p; for clen>1 (64, 4096, …) and a non-multiple $len(from), the final chunk[1] runs past from64[1].HEAPu8csPush1Z, which reorders by the u64 at chunk[0], so $last(chunksdata) is not the overrunning chunk; the if (last[1]>from64[1]) last[1]=from64[1] clamp misses it.SORTu64next→SORTu64x then $u8take(...,sizeof(u64)) reads OOB.SORTu64 over an element count not a multiple of 64 (e.g. 65 u64) so a second merge level (clen=64) runs.None.
Clamp at chunk construction, drop the unreliable post-hoc clamp.
SORT test case with 65 (and 4097) u64 inputs; confirm OOB read under ASan.p += clen, set chunk[1] = p > from64[1] ? (u8c*)from64[1] : (u8c*)p; and remove the $last(chunksdata) clamp.