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:
- Security Advisory: Multiple Vulnerabilities in llama.cpp GGUF Format Parsers 135266653 (May 15)
