ggml GGUF loader allows integer overflow and enum UB

Fuzzing of the GGUF model loader shared by llama.cpp and other ggml-based tools has exposed two bugs that invoke undefined behavior while loading tensor metadata, before safety checks can reject a bad file.

The first flaw is in the guard that is supposed to ensure a tensor’s total element count fits in a signed 64-bit integer. That guard multiplies the shape dimensions first, so an oversized product overflows before any check runs. Shapes that place a zero extent after an already overflowing prefix also pass today: the final product looks zero, the positive-count test is skipped, and the earlier wrap is never noticed.

The second flaw reads the on-disk tensor type straight into a C++ enum. A value outside the enum’s defined range is undefined behavior, so the range test that follows comes too late.

Both cases reproduce on current ggml under AddressSanitizer and UndefinedBehaviorSanitizer with a libFuzzer harness around GGUF loading. Reporter BEKO2210 supplied small loader-side fixes that reject the bad inputs without changing behavior for valid files, and said their own loader now blocks the same cases before calling into GGUF initialization.

GGUF is a common interchange format for local LLM weights. Loaders that hit undefined behavior on crafted tensors are a reliability and security concern for any tool that accepts models from untrusted sources.