GPU VulnDB

Database/AI/ML frameworks & serving

llama.cpp: integer overflow in GGUF tensor size padding yields an undersized data blob and out-of-bounds reads

CVSS 6.9CVE-2026-116840AI/ML frameworks & servingcurated

Impact

A GGUF file whose tensor size sits near SIZE_MAX pads to zero, bypassing the size check added for CVE-2025-53630. The loader then allocates an undersized data blob while consumers continue to read the declared tensor extent, so any code path that loads the model reads past the allocation. On a GPU node this is reached by whatever supplies model files - a tenant uploading a quantized model, a model-registry sync, or a pulled community artifact - and the process doing the loading is the serving process that owns the GPU. The record describes out-of-bounds reads with high availability impact and does not claim code execution; treat it as crash and memory-disclosure risk rather than confirmed takeover.

Who can reach it

Anyone who can place or substitute a GGUF file that an operator or tenant then loads (CVSS vector is local with user interaction, no privileges). No authentication to llama.cpp itself is involved - the attack is via the model artifact.

What to do

Upgrade to llama.cpp build b11275 or later (fix commit a6ea155d) and restart llama-server or whatever embeds the library. No node drain or firmware work; a rolling restart of inference workers is enough. Until then, only load GGUF files from sources you control and reject tensor sizes near SIZE_MAX at ingest.

References

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.