ollama - 💡(How to fix) Fix GGUF/GGML parser runs on untrusted model files — native parsing of attacker-controlled binary data

CWE-120: GGUF/GGML Parser Runs on Untrusted Model Files — Native Code Attack Surface

Severity: LOW-MEDIUM (CVSS 4.0)

Location

llm/server.go:

func LoadModel(model string, maxArraySize int) (*ggml.GGML, error) {
    f, _ := os.Open(model)
    ggml, _ := ggml.Decode(f, maxArraySize)
    return ggml, err
}

server/model.go:

func parseFromModel(ctx context.Context, name model.Name, ...) {
    blob, _ := os.Open(blobpath)
    f, _ := ggml.Decode(blob, -1)
}

server/images.go:

f, _ := gguf.Open(m.ModelPath)

Description

Model files downloaded from registries are parsed by GGUF/GGML native parsers (ggml.Decode, gguf.Open). These parsers handle binary file formats that include:

• Variable-length arrays
• Nested tensor metadata
• Custom key-value stores
• Raw tensor data offsets

If a malicious model file contains crafted binary data (e.g., integer overflows in array sizes, buffer over-reads in string parsing, invalid offsets), the parser could crash or exhibit undefined behavior. While this is a client-side risk (the user chose to pull the model), the default registry (ollama.com) and the ability to configure custom registries means users may trust models from unknown sources.

This is partially mitigated by SHA256 digest verification, which ensures the file hasn't been tampered with in transit — but does NOT protect against a malicious publisher who created the model with a valid digest.

Impact

A carefully crafted GGUF file from an untrusted registry could crash the Ollama server, or in a worst-case scenario (parser memory corruption), potentially achieve code execution in the Ollama process.

Remediation

1. Run GGUF/GGML parsing in a sandboxed subprocess
2. Add fuzz testing harness for the GGUF/GGML parser (AFL++ or Go fuzzing)
3. Validate critical fields before allocation (array sizes, string lengths, offsets)
4. Document the risk: "Only pull models from trusted publishers"