llama.cpp EUVD-2026-54280

Exploitation requires a target Android device running an application built with llama.cpp JNI wrapper builds b1886-b7445. The application must invoke both bench_1model() and free_1context() from separate concurrent threads - applications that call these functions exclusively from a single thread are not exploitable via this race condition. The attacker must be able to influence the timing of concurrent JNI calls, either by controlling application logic or through inter-process means on the same device. User interaction is required per the CVSS UI:P rating, meaning the victim must trigger the benchmarking code path. Exploitation is further constrained by CVSS AC:H: the attacker must reliably win the race window AND achieve deterministic heap layout for vtable hijacking, which Android mitigations including ASLR and hardware memory tagging on ARMv9 devices complicate considerably. The CVSS PR:N rating confirms no elevated Android permissions are required once the concurrent call condition is met.

The CVSS 4.0 score of 7.3 (AV:L/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H) accurately reflects a constrained but impactful vulnerability. AV:L confirms the attack is bounded to local Android device context rather than a network-reachable endpoint, substantially limiting the realistic attacker population. AC:H reflects the genuine difficulty of reliably winning a race condition and achieving deterministic heap layout for vtable hijacking against Android runtimes that enforce ASLR and, on ARMv9 devices, hardware memory tagging (MTE). PR:N is consistent with the JNI layer being accessible to any thread within the application process without requiring elevated Android permissions. UI:P (user interaction required) further narrows the exploitation window to moments when the victim triggers a benchmark operation. No EPSS data was provided; no CISA KEV listing confirms active exploitation, placing this in the category of a serious but currently theoretical threat. Real-world priority is highest for Android applications that invoke both benchmarking and context-management JNI calls concurrently from multiple threads; single-threaded deployments are not exposed.

An attacker with the ability to influence thread scheduling in an Android application using a vulnerable llama.cpp build triggers bench_1model() and free_1context() concurrently from two threads, racing to free the llama_context heap object while the benchmark routine still holds a live reference. On a successful race win, the attacker floods the freed heap region via spray with a crafted buffer embedding a fake vtable, overwriting the vtable pointer at offset +0x30 in llama_batch_allocr so that a subsequent clear() virtual call dispatches to an attacker-controlled function pointer, yielding arbitrary code execution within the app process. No public exploit code is known at time of analysis, though the CVE disclosure documents both the vulnerable function pair and the exact vtable offset, materially reducing development effort.