gguf : harden loader against malformed tensor dims and metadata types

[harrison001]

Overview

Hardens the GGUF loader (gguf_init_from_buffer / gguf_init_from_reader) against two crashes reachable from a crafted, untrusted .gguf file. The loader is the trust boundary for any app that loads user-supplied GGUF (e.g. llama-server and downstream tools), so a malformed model file should fail cleanly rather than crash the process.

Additional information

Both issues were found while fuzzing gguf_init_from_buffer with libFuzzer + AddressSanitizer on current master.

1. SIGFPE (division by zero) on a zero tensor dimension

Dimensions are validated as ne[j] >= 0, but the representability check then divides by ne[1..3]:

if (ok && ((INT64_MAX/info.t.ne[1] <= info.t.ne[0]) || ...

A tensor with n_dims >= 2 and ne[1] == 0 (allowed by the >= 0 check) triggers INT64_MAX / 0 → SIGFPE.

AddressSanitizer: FPE ... gguf.cpp in gguf_init_from_reader(...)

Minimal PoC (65 bytes, base64):
R0dVRgMAAAABAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAB0AgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

2. Assertion abort on wrong-typed general.alignment

The alignment key is read as uint32 without checking its declared type; a file declaring general.alignment with any non-UINT32 type hits GGML_ASSERT(type_to_gguf_type<T>::value == type) → ggml_abort().

gguf.cpp: GGML_ASSERT(type_to_gguf_type<T>::value == type) failed

Minimal PoC (62 bytes, base64):
R0dVRgMAAAAAAAAAAAAAAAEAAAAAAAAAEQAAAAAAAABnZW5lcmFsLmFsaWdubWVudAgAAAABAAAAAAAAAHg=

Fix

• Skip the overflow check when any ne[j] == 0 (element count is 0, trivially representable).
• Validate that general.alignment is GGUF_TYPE_UINT32 before reading it; otherwise fail cleanly.

Reproduce: printf '<base64>' | base64 -d > poc.gguf, then load it through any gguf_init_from_* path.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES — the two issues were found via libFuzzer + AddressSanitizer fuzzing of gguf_init_from_buffer on master. The fix and the minimal PoCs were drafted with the help of an AI coding assistant and reviewed/verified by me. I am responsible for all submitted changes. Happy to adjust the approach if maintainers prefer different checks.

[harrison001]

Disclosure: this issue was found via libFuzzer + AddressSanitizer fuzzing of gguf_init_from_buffer on current master. The fix and the minimal PoCs were drafted with the help of an AI coding assistant and reviewed/verified by me. Happy to adjust the approach if maintainers prefer a different check.

[JohannesGaessler]

Please add corresponding test cases to tests/test-gguf.cpp.

[harrison001]

Please add corresponding test cases to tests/test-gguf.cpp.

Added test cases in 3cd5206: two handcrafted files in tests/test-gguf.cpp — a general.alignment key with a wrong (non-u32) type, and a tensor with a zero-size dimension. Both used to crash before (assert-abort and SIGFPE); with the fix they load cleanly. Full suite passes (164/164).

[end2benzing]

I ran an unrelated fuzzing campaign against gguf_init_from_buffer
on current master (libFuzzer + ASan/UBSan, ~400k iterations) and hit the same SIGFPE at
gguf.cpp:685 via a zero tensor dimension (ne[1] == 0 passing the >= 0 check, then
INT64_MAX / 0). Confirms this reproduces reliably and isn't a one-off.

Also did a manual pass on the surrounding overflow check — the ne[0]/ne[2]/ne[3]
multiplications can't independently overflow due to the || short-circuit, so the zero-check
in this PR looks like it fully covers the defect rather than being a partial fix.

found via an AI-assisted fuzzing/static-analysis pipeline I built and ran myself,
I reviewed and verified the crash and the analysis above personally.

No new PoC needed since this PR's reproducer already covers it — just flagging that it's a
live, currently-exploitable-by-anyone-loading-untrusted-models bug on master, not theoretical,
in case that helps with review priority.

[CISC]

LGTM @ggerganov?

[ggerganov]

Seems OK.

My memory is a bit fuzzy on the topic of zero-sized tensors (i.e. ne[k] == 0). There is explicit logic there to allow them, but at the same time, I don't think there is any purpose to do so - these are basically empty tensors.

[Green-Sky]

ggml-org/ggml#1517 (comment) They are to be allowed.

safetensors allows them and they are used in some models (diffusion stuff) to tag it for a specific feature, instead of kv.