github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-07 00:22:43 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[PR #14175] fs/gguf: validate tensor dimension count in readTensor #40424

New Issue
Open
opened 2026-04-23 01:19:17 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-23 01:19:17 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/ollama/ollama/pull/14175
Author: @kolega-ai-dev
Created: 2/9/2026
Status: 🔄 Open

Base: main ← Head: v11-finding_28

📝 Commits (1)

  • 5864c7c fs/gguf: validate tensor dimension count in readTensor

📊 Changes

1 file changed (+5 additions, -0 deletions)

View changed files

📝 fs/gguf/gguf.go (+5 -0)

📄 Description

Vulnerability identified and fix provided by Kolega.dev

Unbounded Tensor Shape Dimension Allocation

Location

fs/gguf/gguf.go:93-128 — readTensor() function

Description

The readTensor() function reads a uint32 dimension count from a GGUF file and directly allocates a []uint64 slice of that size without bounds checking. Since GGUF files can be supplied by users via /api/create, an attacker can craft a malicious file with dims=4294967295 (max uint32), attempting to allocate 32GB+ of memory. This is a denial-of-service via memory exhaustion.

Analysis Notes

Real tensor dimensions in ML models are limited to at most 4, consistent with the GGML_MAX_DIMS constant defined in ml/backend/ggml/ggml/include/ggml.h. The C++ GGUF parser (ml/backend/ggml/ggml/src/gguf.cpp:528) already validates n_dims > GGML_MAX_DIMS, but the Go parser did not.

Fix Applied

Added a bounds check on the dims value before slice allocation, rejecting any value greater than 4. This matches the GGML_MAX_DIMS limit enforced by the C/C++ GGML library and the C++ GGUF parser, ensuring consistency across both parsers. The error message follows the existing pattern in the file.

Tests/Linters Ran

  • gofmt -d fs/gguf/gguf.go — no formatting changes needed
  • go vet ./fs/gguf/... — passed with no issues
  • go test ./fs/gguf/... -v -count=1 — all 3 tests passed (TestValue, TestValues, TestRead)

Contribution Notes

  • Commit message follows the <package>: <short description> convention specified in CONTRIBUTING.md
  • No new dependencies added
  • Existing tests confirm valid GGUF files with 2-dimension tensors continue to parse correctly

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/ollama/ollama/pull/14175 **Author:** [@kolega-ai-dev](https://github.com/kolega-ai-dev) **Created:** 2/9/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `v11-finding_28` --- ### 📝 Commits (1) - [`5864c7c`](https://github.com/ollama/ollama/commit/5864c7c7384a5222d37f5aba7d71838e74064b3f) fs/gguf: validate tensor dimension count in readTensor ### 📊 Changes **1 file changed** (+5 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `fs/gguf/gguf.go` (+5 -0) </details> ### 📄 Description *Vulnerability identified and fix provided by [Kolega.dev](https://kolega.dev/)* ## Unbounded Tensor Shape Dimension Allocation ## Location `fs/gguf/gguf.go:93-128` — `readTensor()` function ## Description The `readTensor()` function reads a `uint32` dimension count from a GGUF file and directly allocates a `[]uint64` slice of that size without bounds checking. Since GGUF files can be supplied by users via `/api/create`, an attacker can craft a malicious file with `dims=4294967295` (max uint32), attempting to allocate 32GB+ of memory. This is a denial-of-service via memory exhaustion. ## Analysis Notes Real tensor dimensions in ML models are limited to at most 4, consistent with the `GGML_MAX_DIMS` constant defined in `ml/backend/ggml/ggml/include/ggml.h`. The C++ GGUF parser (`ml/backend/ggml/ggml/src/gguf.cpp:528`) already validates `n_dims > GGML_MAX_DIMS`, but the Go parser did not. ## Fix Applied Added a bounds check on the `dims` value before slice allocation, rejecting any value greater than 4. This matches the `GGML_MAX_DIMS` limit enforced by the C/C++ GGML library and the C++ GGUF parser, ensuring consistency across both parsers. The error message follows the existing pattern in the file. ## Tests/Linters Ran - `gofmt -d fs/gguf/gguf.go` — no formatting changes needed - `go vet ./fs/gguf/...` — passed with no issues - `go test ./fs/gguf/... -v -count=1` — all 3 tests passed (TestValue, TestValues, TestRead) ## Contribution Notes - Commit message follows the `<package>: <short description>` convention specified in CONTRIBUTING.md - No new dependencies added - Existing tests confirm valid GGUF files with 2-dimension tensors continue to parse correctly --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-04-23 01:19:17 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#40424
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?