[<prev] [next>] [day] [month] [year] [list]
Message-ID: <tencent_7FD8DEDF5B29E7A9EEA19C0EC8D78C734609@qq.com>
From: 135266653@...com
To: oss-security@...ts.openwall.com
Subject: Security Advisory: Multiple Vulnerabilities in llama.cpp GGUF Format Parsers
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.
Download attachment "GGUF_Security_Advisory.md" of type "application/octet-stream" (10734 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
