GPU VulnDB

Database/AI/ML frameworks & serving

llama.cpp: malloc/delete mismatch in the Android JNI batch wrapper corrupts the heap

CVSS 8.5CVE-2026-43622AI/ML frameworks & servingcurated

Impact

The allocation in new_1batch() uses malloc() while free_1batch() releases it with the C++ delete operator, corrupting allocator metadata. The reachable path is the LLaMA-Android JNI binding, not the server or CLI builds a datacenter typically runs, so fleet exposure is limited to hosts that build and load the Android binding. Where it is reachable, the result is a process crash and, depending on allocator state, possible code execution in the inference process. Operators running llama.cpp only via llama-server or the CLI are not affected by this code path.

Who can reach it

Local, requires user interaction per the vendor vector: an actor who can drive the JNI binding (load a crafted model or call the binding directly). No authentication to a network service is involved.

What to do

Upgrade llama.cpp to build b7446 or later, which carries commit 5c0d188. Rollout is a rebuild of the binary and a restart of any serving process; no node drain or reboot. If you do not ship the Android JNI binding, no action is needed.

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.