oss-sec mailing list archives

Security Advisory: Multiple Vulnerabilities in llama.cpp GGUF Format Parsers


From: 135266653 () qq com

Security Advisory: Multiple Vulnerabilities in llama.cpp GGUF Format Parsers

Date: 2026-05-15
Affected Software: llama.cpp (GGUF format parser implementation)
Repository: https://github.com/ggml-org/llama.cpp
Severity: Critical / High / Medium

SUMMARY

Multiple security vulnerabilities were discovered in the GGUF file parsing code
within gguf.cpp (C++ core) and gguf_reader.py (Python reference implementation).
These range from critical out-of-bounds read/arbitrary file seek to high-severity
memory exhaustion and several medium-severity issues.

DETAILS

V-01 [CRITICAL - CVE Candidate] Missing Upper Bound on Alignment Value
- File: gguf.cpp, lines 560-567
- The general.alignment KV value is only validated for power-of-2 and non-zero,
  but has NO upper bound check.
- Setting alignment to 0x80000000 (or any value >= 2^16) causes GGML_PAD macro
  integer overflow on 32-bit systems, enabling arbitrary file seek and OOB read.
- gguf.cpp:703 uses GGML_PAD result in gguf_fseek().
- Same issue exists in Python gguf_reader.py.

V-02 [HIGH] Excessive GGUF_MAX_STRING_LENGTH (1GB) Enables OOM
- File: gguf.cpp, lines 18-19
- #define GGUF_MAX_STRING_LENGTH (1024*1024*1024)
- #define GGUF_MAX_ARRAY_ELEMENTS (1024*1024*1024)
- Combined: 1GB strings x 1GB array elements = theoretical 1EB allocation.
- std::string::resize() triggers std::bad_alloc on 32-bit systems.

V-03 [HIGH] Python Reference Missing n_dims Upper Bound
- File: gguf_reader.py, lines 267-272
- C++ rejects n_dims > GGML_MAX_DIMS (4); Python has NO check.
- n_dims = 0xFFFFFFFF causes ~32GB read attempt via memory mapping.
- Affects all Python GGUF tools (conversion, inspection).

V-04 [MEDIUM] int64 to size_t Implicit Conversion Risk
- File: gguf.cpp, lines 468-486
- n_tensors/n_kv read as int64_t, compared with SIZE_MAX/sizeof(...).

V-05 [MEDIUM] gguf_type Enum Deserialized Without Bounds Check
- File: gguf.cpp, lines 324-331
- int32_t from file directly cast to enum gguf_type(tmp) with no validation.
- Out-of-range values cause gguf_type_size() to return 0 (div-by-zero risk).

V-06 [MEDIUM] Division by Zero via Zero blck_size
- File: gguf.cpp, lines 662-668
- ggml_blck_size() returning 0 leads to ne[0]/blck_size division by zero.

AFFECTED VERSIONS

All versions of llama.cpp using GGUF format (all git revisions since GGUF v3).
All versions of gguf-py Python reference implementation.

REMEDIATION

V-01: Add upper bound: alignment < 4 || alignment > 1048576  [IMMEDIATE]
V-02: Reduce GGUF_MAX_STRING_LENGTH to 64MB                 [HIGH]
V-03: Add if n_dims[0] > 4: raise ValueError                [HIGH]
V-04: Use consistent types or check PTRDIFF_MAX              [MEDIUM]
V-05: Add read() bounds check for gguf_type                  [MEDIUM]
V-06: Harden zero-check in tensor parsing                    [MEDIUM]

TIMELINE
2026-05-15: Vulnerabilities discovered during code audit
2026-05-15: This advisory published

Full advisory with PoC code and CVSS scores attached.

Attachment: GGUF_Security_Advisory.md
Description:


Current thread: