gguf : reject non-u32 general.alignment

[Adel-Ayoub]

Overview

A GGUF file whose general.alignment key is stored with a non-u32 type (or as an
array) crashes the loader instead of being rejected. gguf_init_from_reader() reads it
via gguf_get_val_u32(), which asserts the stored type (ggml/src/gguf.cpp:194);
GGML_ASSERT calls abort() in release builds, so a corrupt/crafted model takes down
every gguf_init_from_* caller (llama-cli, llama-server, ...) with SIGABRT.

The u32 requirement is already enforced on the write side (gguf_check_reserved_keys),
and the bad-value case is already rejected gracefully two lines below — this does the
same for a bad type: validate it and return nullptr.

Before / after, loading a GGUF with an int32 general.alignment:

- gguf.cpp:194: GGML_ASSERT(type_to_gguf_type<T>::value == type) failed   (SIGABRT)
+ gguf_init_from_reader: key 'general.alignment' must have type u32       (clean nullptr)

Additional information

Adds a HANDCRAFTED_KV_BAD_ALIGN_TYPE regression case to tests/test-gguf.cpp. ctest -R gguf passes.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: No

[ggml-gh-bot]

Hi @Adel-Ayoub, thanks for your contribution!

Per our contribution guidelines, the automated PR checker found the following issue(s) that need your attention:

• AI-generated content: This project does not accept PRs, descriptions or commit messages that are fully or predominantly AI-generated. If you have used AI to assist you in writing code, please make sure to disclose that explicitly.

---

Please note that maintainers reserve the right to make final decisions on PRs. If you believe there is a mistake, please comment below.