Fix out-of-bounds write in gguf_q4_0/q4_1_to_float second nibble loop

[gigioneggiando]

Problem

gguf_q4_0_to_float() and gguf_q4_1_to_float() dequantize each block with two separate 16-iteration loops (lower nibbles, then upper nibbles). The break on if (++i == count) only exits whichever loop is currently running:

for (uint32_t j = 0; j < 16; j++) { ...; if (++i == count) break; }  // lower
/* nothing stops us here */
for (uint32_t j = 0; j < 16; j++) { ...; if (++i == count) break; }  // upper

If count is reached partway through the first loop, that loop breaks correctly, but the second loop still runs unconditionally and writes up to 16 more floats past the end of dst, because i is already == count and its own ++i == count check can never fire again.

Callers size the destination as count * sizeof(float) (this is exactly what gguf_tensor_to_float() does: malloc(tensor->num_weights * sizeof(float))). So whenever count lands inside a block's first half, the destination is overrun. Since count is derived from an attacker-controlled tensor dimension in a downloaded .gguf file, this is a heap out-of-bounds write reachable by dequantizing/inspecting a crafted Q4_0/Q4_1 tensor (e.g. inspect-tensor, compare, or any gguflib caller).

Reproduction

Built release (-DNDEBUG) under AddressSanitizer, driving the real gguf_q4_0_to_float with count = 1 and a malloc(4) destination:

==ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 4 ...
    #0 gguf_q4_0_to_float gguflib.c:835
SUMMARY: AddressSanitizer: heap-buffer-overflow gguflib.c:835 in gguf_q4_0_to_float

Fix

Stop the block loop as soon as i == count, before entering the upper-nibble loop. No integer-overflow trickery is involved and no build flag is required to trigger the bug, so this is a plain logic fix. It is also strictly more correct for any legitimate count that is not a multiple of the 32-weight block (the old code would write past the caller's buffer there too).

Verified with the same ASan harness after the patch: the call returns cleanly, no out-of-bounds write.

I ran this by a small local audit of the GGUF read path against untrusted model files; happy to share more detail privately if useful. No CVE or public advisory from my side.