CVE-2026-70640 in llama.cpp
Summary
by MITRE • 08/07/2026
llama.cpp builds b1886 through b7445 contain a race condition use-after-free vulnerability in the LLaMA-Android JNI wrapper where bench_1model() and free_1context() lack synchronization, allowing Thread A to operate on freed memory while Thread B concurrently frees the llama_context. Attackers can exploit this by performing heap spray with attacker-controlled data containing a fake vtable to hijack the vtable pointer at offset +0x30, causing llama_batch_allocr::clear() to dereference arbitrary memory and achieve remote code execution.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/07/2026
The vulnerability exists within the llama.cpp library version range b1886 through b7445, specifically affecting the LLaMA-Android JNI wrapper implementation. This race condition manifests as a use-after-free scenario that occurs when multiple threads attempt concurrent operations on the same memory resources without proper synchronization mechanisms. The flaw is particularly dangerous because it combines timing dependencies with memory management operations that create exploitable conditions for privilege escalation attacks.
The technical root cause stems from insufficient thread synchronization between the bench_1model() function and free_1context() operations within the JNI wrapper layer. When Thread A executes bench_1model() while Thread B simultaneously calls free_1context(), the llama_context object becomes prematurely deallocated while Thread A may still be accessing it. This creates a classic race condition where the memory previously allocated to the context structure gets freed and potentially reallocated before Thread A completes its operations, leading to use-after-free conditions that can be exploited by malicious actors.
From an operational impact perspective, this vulnerability allows for remote code execution through carefully crafted heap spray attacks that leverage attacker-controlled data structures. The exploitation technique involves placing a fake vtable at offset +0x30 within the heap spray payload, effectively hijacking the virtual table pointer that controls method dispatch behavior. When the llama_batch_allocr::clear() function attempts to dereference this corrupted vtable pointer, it follows execution control flow to arbitrary memory locations determined by the attacker's payload rather than legitimate code paths.
The vulnerability aligns with CWE-367, which specifically addresses time-of-check to time-of-use race conditions, and maps to ATT&CK technique T1059.007 for command and scripting interpreter along with T1021.004 for remote services. The attack vector can be classified as a memory corruption vulnerability that enables privilege escalation through heap manipulation techniques commonly used in advanced exploit development. Organizations using affected versions of llama.cpp should immediately implement mitigations such as thread synchronization primitives, proper memory management protocols, and input validation measures to prevent exploitation.
Security practitioners should monitor for signs of heap spraying activities and implement defensive measures including address space layout randomization, stack canaries, and runtime memory protection mechanisms. The vulnerability demonstrates the critical importance of proper concurrency control in shared memory environments and highlights the need for comprehensive testing of multi-threaded operations in mobile application frameworks like Android JNI wrappers. Mitigation strategies should include immediate patching of affected versions and implementation of robust thread synchronization controls to prevent similar race conditions from occurring in other components of the software stack.