fs/ggml: malicious GGUF crashes decoder — unvalidated string length (makeslice panic / DoS)

快速结论：该报错发生在使用 Ollama 加载或创建恶意的 GGUF 模型文件时，由于 GGUF 解码器未校验元数据字符串长度，导致进程崩溃（makeslice panic / DoS）。优先排查是否使用了不受信任的 GGUF 模型文件，并更新 Ollama 版本至包含修复的版本。

问题场景

用户在使用 Ollama（版本详情见后）加载模型（如 ollama pull、ollama create）时，如果模型文件是恶意构造的 GGUF 格式文件，Ollama 的 GGUF 解码器会因未经验证的字符串长度而崩溃。具体报错为 makeslice: len out of range 或 slice bounds out of range，导致进程直接退出（DoS 拒绝服务攻击）。

报错原文

panic: runtime error: makeslice: len out of range

或

panic: runtime error: slice bounds out of range

原因分析

Ollama 的 GGUF 解码器在 fs/ggml/gguf.go 文件的 readGGUFString 函数中，从文件二进制数据中读取 uint64 类型的长度值后直接转为 int，未做任何边界检查。攻击者可以通过制作 GGUF 文件，将元数据字符串长度设置为超大值（如 2^64-1），导致：

如果长度大于 len(llm.scratch)，调用 make([]byte, length)，可能因 makeslice: len out of range 而 panic 或导致内存耗尽（OOM）。
如果长度产生负数（uint64 到 int 转换），调用 llm.scratch[:length] 会触发 slice bounds out of range panic。

注意：这不是内存损坏（Go 语言内存安全），但会导致拒绝服务（DoS）。

环境排查

确认 Ollama 版本：该漏洞在 main 分支提交 964ea42（2026-07-03）上确认存在。如果版本比此更新，可能已修复。
确认使用的 GGUF 模型文件来源：怀疑是恶意模型时，检查文件大小（仅需 36 字节即可复现）或使用其他工具验证其完整性。

解决步骤

升级 Ollama 版本：该问题已在对应的 PR #17062 中修复，并包含在下一个正式发布版本中。请升级到最新版 Ollama（修复后的版本，例如 v0.6.0 或更高，具体以官方发布为准）。
临时规避（如无法立即升级）：避免加载任何来源不可信的 GGUF 模型文件。如果必须加载，在加载前对模型文件进行手动检查（如使用十六进制编辑器检查 GGUF 头部元数据字符串长度字段是否异常大）。
开发者自行编译：若您从源码编译 Ollama，请拉取 main 分支的最新代码（必须包含 #17062 的合并），或手动将 fs/ggml/gguf.go 中的 readGGUFString 函数加入长度校验逻辑。