CVE-2026-43622 in llama.cpp
Summary
by MITRE • 08/06/2026
llama.cpp builds b1886 through b7445 contain a double free vulnerability in the LLaMA-Android JNI wrapper where new_1batch() allocates memory using malloc() while free_1batch() deallocates it using the C++ delete operator, causing heap metadata corruption. Attackers can trigger this memory management mismatch to cause denial of service through process crashes or potentially achieve arbitrary code execution depending on allocator state.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/06/2026
The vulnerability exists within the llama.cpp library version range b1886 through b7445 specifically affecting the LLaMA-Android JNI wrapper implementation. This represents a critical memory corruption issue that stems from an improper memory management pattern in the Android native interface layer. The flaw manifests when the new_1batch() function allocates memory using the standard C library malloc() function while the corresponding free_1batch() function releases the same memory using C++ delete operator instead of free(). This fundamental mismatch between allocation and deallocation mechanisms creates a double free condition that corrupts heap metadata structures.
The technical nature of this vulnerability aligns with CWE-415, which describes improper free conditions in software applications. The memory management inconsistency occurs at the boundary between Java Native Interface (JNI) layers where C++ memory management conventions conflict with standard C library allocation patterns. When the JNI wrapper handles batch processing operations for LLaMA model inference on Android devices, the mismatch causes heap corruption that manifests as undefined behavior during memory deallocation. This particular implementation flaw violates the fundamental principle of matching malloc() with free() and new[] with delete[], creating a scenario where the same memory block gets freed twice through different mechanisms.
The operational impact of this vulnerability extends beyond simple denial of service conditions to potentially enable arbitrary code execution under specific circumstances. Process crashes occur reliably when the heap metadata corruption is severe enough to trigger memory allocator errors or segmentation faults during deallocation. However, in less predictable scenarios where the allocator state allows continued operation despite corruption, attackers may be able to manipulate the heap layout to achieve code execution privileges. The vulnerability affects Android applications that utilize the LLaMA-Android JNI wrapper for large language model inference, particularly those deploying on devices with constrained memory resources where heap corruption patterns can be more easily exploited.
Mitigation strategies should focus on ensuring proper memory management consistency within the JNI wrapper implementation. The most effective approach involves modifying either the allocation or deallocation mechanisms to maintain consistency - either changing new_1batch() to use new[] and delete[] consistently, or converting free_1batch() to use free() instead of delete. Additionally, input validation and bounds checking should be implemented to prevent malicious inputs from triggering the vulnerable code path. The vulnerability can be addressed through patching the JNI wrapper functions in the llama.cpp library to maintain consistent memory management practices across all allocation and deallocation operations. Organizations should also implement runtime protections such as heap corruption detection mechanisms and address space layout randomization where possible to reduce exploitability. This vulnerability demonstrates the importance of maintaining strict consistency in memory management patterns, particularly when interfacing between different programming language environments like Java and C++ through JNI boundaries.
The attack surface for this vulnerability is primarily limited to applications that utilize the LLaMA-Android JNI wrapper for inference operations, making it specific to mobile applications using large language models on android platforms. The exploitation requires an attacker to trigger the specific code path that calls both new_1batch() and free_1batch() functions in sequence, which can be achieved through malformed input or crafted batch processing requests. This type of vulnerability is commonly classified under the attack technique of memory corruption exploits in the MITRE ATT&CK framework, specifically within the T1059 category of command and scripting interpreters where process manipulation occurs through memory corruption vulnerabilities. The vulnerability's presence in a widely-used library like llama.cpp means that numerous Android applications could be affected, making it particularly concerning from a security perspective.