EUVD-2026-54276
GHSA-p56f-gv6x-v6mg
Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Local attack vector via malicious model file loaded by the user (UI:R); no privileges required on the Android side; full CIA impact within the app process if heap corruption leads to RCE.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
Lifecycle Timeline
3DescriptionCVE.org
llama.cpp builds b1886 through b7445 contain an integer overflow vulnerability in the LLaMA-Android JNI wrapper where the new_1batch() function multiplies sizeof(llama_seq_id) by an attacker-controlled n_seq_max parameter without overflow validation, causing heap buffer allocation to wrap and allocate insufficient memory. Attackers can exploit this by providing a crafted n_seq_max value through a malicious model file or JNI call to trigger heap corruption and achieve denial of service or arbitrary code execution on Android applications using the LLaMA-Android binding.
AnalysisAI
Integer overflow in the llama.cpp LLaMA-Android JNI wrapper (builds b1886 through b7445) allows heap corruption through a crafted n_seq_max parameter, enabling denial of service or arbitrary code execution within Android applications that load untrusted GGUF model files. The flaw exists in the new_1batch() function, which multiplies sizeof(llama_seq_id) by an attacker-controlled value without bounds checking, causing heap allocation to wrap and undersize the buffer. No public exploit has been identified at time of analysis and this CVE is not in CISA KEV; a patched release (b7446) is confirmed available from the upstream ggml-org repository.
Technical ContextAI
CWE-122 (Heap-based Buffer Overflow) describes this class of flaw: the allocation size is computed as sizeof(llama_seq_id) multiplied by the attacker-controlled n_seq_max integer parameter inside new_1batch(), a function in the LLaMA-Android JNI wrapper (examples/llama.android). When n_seq_max is crafted to be sufficiently large, the multiplication overflows the integer type before being passed to the allocator, yielding a heap allocation smaller than the volume of data subsequently written. The result is a classic heap underallocation leading to out-of-bounds writes. The Android JNI layer bridges Java/Kotlin application code to the native llama.cpp C++ library, and this vulnerability exists specifically in that boundary layer. No CPE string was provided; affected artifacts are the llama.cpp project (ggml-org/llama.cpp) builds b1886 through b7445, Android binding component only. The fix commit is at https://github.com/ggml-org/llama.cpp/commit/5c0d18881e0e9794c96b2602736b758bac9d9388 and was released as build b7446.
RemediationAI
Upgrade to llama.cpp build b7446 or later, which is confirmed available at https://github.com/ggml-org/llama.cpp/releases/tag/b7446 and addresses the integer overflow via the upstream commit https://github.com/ggml-org/llama.cpp/commit/5c0d18881e0e9794c96b2602736b758bac9d9388. As a compensating control prior to patching, restrict Android applications from loading GGUF model files sourced from user-controlled or untrusted locations - this eliminates the primary delivery vector at the cost of reduced user flexibility. Additionally, input validation of the n_seq_max parameter at the JNI boundary before it reaches new_1batch() can prevent the overflow; however, this is a code-level mitigation requiring a custom build. Applications that exclusively load cryptographically signed or vendor-pinned model files from controlled repositories are not practically exploitable via the documented attack path.
Same weakness CWE-122 – Heap-based Buffer Overflow
View allVendor StatusVendor
SUSE
Severity: ImportantShare
External POC / Exploit Code
Leaving vuln.today