ollama qwen3next converter unbounded allocation PoC (source-verified)
Proof-of-concept material for a huntr Model Format Vulnerability report
against ollama/ollama,
convert/convert_qwen3next.go:226-233 (qwen3NextInferNextNPredictLayers).
The bug, verified against the live source fetched directly today
1var n int64
2if err := binary.Read(f, binary.LittleEndian, &n); err != nil {
3 f.Close()
4 return 0, err
5}
6b := bytes.NewBuffer(make([]byte, 0, n))
7if _, err = io.CopyN(b, f, n); err != nil {
8 f.Close()
9 return 0, err
10}
An 8-byte little-endian int64 length is read directly from an untrusted
model file and used, with no upper-bound check, to pre-allocate a buffer
via make([]byte, 0, n). Three sibling functions in the SAME repository
that read the same kind of field (headerSize) have a working guard
(x/mlxrunner/model/root.go:144, x/imagegen/manifest/manifest.go:295,
x/server/show.go:383 - all three do
if headerSize > N*1024*1024 { return err } before make()) - the fix
pattern is already known and used elsewhere in this codebase, just not
applied here.
evil_qwen3next_header.bin is the 8-byte little-endian int64 header this
function reads first: value 2^48 (281,474,976,710,656) - large enough to
be a real denial-of-service pressure on heap-arena metadata (positive, so
it avoids the separate int64 sign caveat noted below), while still small
enough to encode in 8 bytes.
Reachability: server/create.go:571 -> convert/convert.go:407
(ConvertModel) -> convert/convert.go:414 (parseTensors) is the sole
call chain into model conversion, triggered by the public HTTP route
POST /api/create (server/routes.go:1891) - reachable without
authentication on unprotected local/private deployments.
Honest limits (not swept under the rug)
- No Go toolchain was available on this host to build ollama and run this
live - confidence rests on direct reading of the current source (this
function, the three sibling functions with a working guard, and the call
chain), not a live crash.
n is int64, not uint64 - if the file's 8th byte has the top bit set,
n is negative, which causes a recoverable panic (makeslice: cap out of range), not a large allocation. Real DoS requires n in the positive
range shown above, not merely "attacker sets all bits".- Duplicate note: the sibling instance of this exact pattern in
convert/reader_safetensors.go:41-48 (parseSafetensors, the safetensors
format's own entry point) is ALREADY publicly reported - ollama/ollama
issue #17148 and PR #17149 (opened 2026-07-12 by a third party, still
open/unmerged as of today) describe exactly that file/function. This
report deliberately covers ONLY the separate convert_qwen3next.go
instance, which is NOT touched by PR #17149's diff and remains
unreported.
Impact: Denial of Service - a small (a few bytes) crafted model file with
a qwen3next architecture, imported via the public /api/create endpoint,
can force a large buffer pre-allocation before any content validation.
Suggested fix: Apply the same headerSize > N*1024*1024-style guard already
used in x/mlxrunner/model/root.go, x/imagegen/manifest/manifest.go, and
x/server/show.go to convert_qwen3next.go:226-233 as well.
