CVE-2026-70638

This CVE describes an integer overflow in the llama.cpp batch allocation path, but the official framing misdirects accountability. The vulnerability is not in the Android JNI wrapper—it is in the native new_batch() function where sizeof(llama_seq_id) * n_seq_max multiplication occurs without overflow validation. If you are defending an Android deployment, hardening only the JNI boundary is insufficient; the native allocation site itself must perform bounds checking or the function remains exploitable by any caller that reaches it, including other bindings, direct API consumers, or future entry points. The n_seq_max parameter originates from the caller, and in embedded deployments the llama.cpp API provides no mechanism to distinguish attacker-controlled values from trusted ones. The type alias llama_seq_id further obscures that you are multiplying by up to 8 bytes, making the overflow easy to miss in code review. Upstream has historically treated new_batch() as a trusted-internal API, leaving overflow validation as an external responsibility—effectively externalizing security costs to every consumer. What you should check: verify whether your binding or wrapper performs overflow-aware bounds checking on n_seq_max before calling the native new_batch(). If it only validates at the JNI/FFI boundary without checking for integer overflow in the multiplication itself, you are exposed. The correct fix requires either adding overflow validation inside new_batch() upstream or calling a checked allocation primitive that enforces a documented upper bound and performs the multiplication safely. The deployment context amplifies this. Unlike sandboxed inference servers, llama.cpp is statically linked into mobile applications. Successful exploitation gives code execution within the application's full privilege context—not a contained inference process. This means the blast radius extends directly to banking, health, or enterprise data accessible to the host app. Additionally, static linking means the disclosure-to-fix window is measured in months, not days, because every affected app must rebuild and ship an update. Prioritize: verify your JNI/FFI layer performs safe arithmetic, not just parameter clamping. If upstream has not deprecated the unchecked new_batch() signature, treat it as a known unsafe interface and migrate to a checked path if available. The recurrence pattern across FFI boundaries—where native libraries assume trusted callers and are then deployed across untrusted boundaries—suggests this class of vulnerability will surface through other entry points within 12-18 months.

Reviewed through automated stages and approved by a human before publication.