llama.cpp: race between bench and context-free in the Android JNI wrapper gives use-after-free code execution

CVSS 7.3CVE-2026-70640AI/ML frameworks & servingcurated

Impact

Builds b1886 through b7445 let two threads in the LLaMA-Android JNI wrapper operate on the same llama_context while one frees it, because bench_1model() and free_1context() have no synchronization. The record describes heap-spray control of the freed object leading to code execution in the inference process. The exposure is in the Android JNI binding, not the server binaries a GPU fleet typically runs, so for datacenter operators this matters only where llama.cpp is embedded through that wrapper; the CVSS vector is local with user interaction. If you do ship that wrapper, an attacker who can drive both calls gets execution with the privileges of the inference process.

Who can reach it

Local, requires the ability to invoke the JNI bench and free paths concurrently in a process embedding llama.cpp's Android wrapper; the vector is rated local with user interaction and no authentication stated.

What to do

Upgrade to llama.cpp build b7446 or later, which adds the missing synchronization, and restart any service that embeds the library. No node reboot or firmware work is involved.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-70640 https://github.com/ggml-org/llama.cpp/commit/5c0d18881e0e9794c96b2602736b758bac9d9388 https://github.com/ggml-org/llama.cpp/releases/tag/b7446 https://www.vulncheck.com/advisories/llama-cpp-b1886-b7445-race-condition-use-after-free-via-llama-android-cpp

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.