Hironabe333/gguf-kv-type-enum-abort-poc

GGUF KV type enum out-of-range causes deterministic llama.cpp runtime abort

Target: GGUF (.gguf) / llama.cpp / llama-cpp-python
Confirmed vulnerable: llama-cpp-python 0.2.90 (llama.cpp commit 1d1ccce67613674c75c9c7e3fa4c1e24e428ba48)
Impact: Deterministic crash / Denial of Service — SIGABRT exit -6
HF Repository: PLACEHOLDER_HF_REPO_URL

---

Summary

A GGUF metadata file contains per-entry KV records, each with a type field (uint32_le). The GGUF specification defines valid types as the gguf_type enum values 0–12 (GGUF_TYPE_UINT8 through GGUF_TYPE_FLOAT64; GGUF_TYPE_COUNT = 13).

In llama-cpp-python 0.2.90 (bundled llama.cpp commit 1d1ccce67), gguf_init_from_file() dispatches on this type value without first validating that it is within [0, 12]. An out-of-range value (e.g., 0xFF = 255 or 13 = GGUF_TYPE_COUNT) causes execution to reach the default: branch of the switch statement at ggml/src/ggml.c:21530:

default: GGML_ABORT("invalid type");

GGML_ABORT calls abort(), which delivers SIGABRT and terminates the process with exit code -6 (134 on some platforms).

The Python gguf package (v0.19.0) rejects the same file safely with a ValueError without crashing, creating a parser/runtime differential exploitable via malicious model distribution.

---

Non-Claims

• No claim that current/latest llama-cpp-python is affected (source inspection suggests current master changed the default case to ok = false; this was NOT runtime-tested).
• No claim of remote code execution, arbitrary code execution, or memory corruption.
• No claim of heap overflow or arbitrary read/write.
• No claim that all GGUF parsers or runtimes are affected.
• This finding covers only the KV entry type enum field — it is distinct from a previously reported issue involving the GGUF header kv_count field.

---

Version Scope

Component	Version	Status
llama-cpp-python	0.2.90	Confirmed vulnerable (runtime tested)
llama.cpp commit	1d1ccce67613674c75c9c7e3fa4c1e24e428ba48	Bundled in 0.2.90
gguf (Python)	0.19.0	Safe — raises ValueError
llama.cpp master	(current)	Source inspection: ok=false default — NOT runtime-tested

---

Setup

pip install llama-cpp-python==0.2.90 gguf==0.19.0

---

Reproduction

Option A — Quick reproduce

python reproduce.py

Expected output:

── baseline.gguf (kv_type=0) ──
  Python GGUFReader: ok=True, error=None
  C runtime (3 runs): exit_codes=[0, 0, 0], all_sigabrt=False
  expected_sigabrt=False → PASS

── kv_type_0xff_invalid.gguf (kv_type=255) ──
  Python GGUFReader: ok=False, error=np.uint32(255) is not a valid GGUFValueType
  C runtime (3 runs): exit_codes=[-6, -6, -6], all_sigabrt=True
  expected_sigabrt=True → PASS

── kv_type_13_invalid.gguf (kv_type=13) ──
  Python GGUFReader: ok=False, error=np.uint32(13) is not a valid GGUFValueType
  C runtime (3 runs): exit_codes=[-6, -6, -6], all_sigabrt=True
  expected_sigabrt=True → PASS

=== Result ===
ALL PASS — T0_CONFIRMED_SIGABRT

Option B — Static check only

python checker.py kv_type_0xff_invalid.gguf

Option C — Manual mutation

python mutation_generator.py

Generates all three GGUF files from scratch.

---

Expected Outputs

File	Python GGUFReader	C runtime (llama-cpp-python 0.2.90)
baseline.gguf	OK	exit 0
kv_type_0xff_invalid.gguf	ValueError	SIGABRT exit -6 (3/3)
kv_type_13_invalid.gguf	ValueError	SIGABRT exit -6 (3/3)

---

Stack Trace (confirmed)

ggml/src/ggml.c:21530: invalid type
ggml_abort+0x11c
gguf_init_from_file+0x3d8

---

Distinctness from Prior Submission (GGUF kv_count)

A separate issue involving the GGUF header kv_count field was previously reported. This finding is distinct on every relevant dimension:

Dimension	This finding (KV type enum)	Prior (kv_count)
Mutated field	Per-entry type byte in KV body	Header kv_count at offset 16
Invariant violated	Type enum must be in [0,12]	Count must equal actual entries
Mechanism	Direct invalid enum → switch default	Inflated count → read overrun → garbage type
Path to crash	Direct	Indirect (count-driven misalignment)
Python exception	ValueError (type validation)	IndexError (count-driven OOB)
Fix location	Range-check type before dispatch	Validate count before loop

Same crash line does not equal same root. The controlled fields, violated invariants, and required remediations are all different.

---

File Inventory

File	Description
baseline.gguf	Valid GGUF (KV type = GGUF_TYPE_UINT8 = 0)
kv_type_0xff_invalid.gguf	Mutant: KV type = 255 (out-of-range)
kv_type_13_invalid.gguf	Mutant: KV type = 13 (== GGUF_TYPE_COUNT)
reproduce.py	End-to-end reproduction script
checker.py	Static KV type validator
mutation_generator.py	Generate all PoC files from scratch
runtime_results.json	Runtime evidence (exit codes, SIGABRT confirmation)
source_analysis.json	Source-level analysis of ggml.c crash path
distinctness_matrix.json	Structured distinctness comparison vs prior submission
hash_matrix.json	SHA256 hashes and differential summary
README.md	This file
SHA256SUMS.txt	Checksums for all files

---

Recommendation

Add an explicit range check on the KV entry type field before the switch dispatch in gguf_init_from_file():

// Before the switch:
if (kv->type < 0 || kv->type >= GGUF_TYPE_COUNT) {
    GGML_LOG_ERROR("invalid gguf type: %d\n", kv->type);
    ok = false;
    break;
}
switch (kv->type) { ... }

Current master (gguf.cpp) appears to have addressed this with a graceful ok = false default case, but users of older llama-cpp-python versions remain at risk.