The core bug here is elementary: new_1batch() allocates with malloc() but free_1batch() deallocates with delete. This mismatch produces a double-free, and any sanitizer-enabled build should catch it immediately. The fact that this shipped in Android JNI builds spanning versions b1886 through b7445 suggests the JNI wrapper lacks automated memory safety testing in its CI pipeline—that's the process failure that allowed this to persist across thousands of commits.
The exploitation path, however, is more nuanced than the CVSS "arbitrary code execution" language suggests. The Android heap allocator (jemalloc) behaves differently than server-side allocators, and the JNI calling context means heap state at crash time depends entirely on whatever Java code executed before the native call. You cannot assume the controlled, repeatable heap grooming conditions that server-side heap exploitation relies on.
What's more interesting than RCE potential is the inference state corruption vector. The batch being freed contains model weights, intermediate activations, and embeddings derived from prompts. An attacker who triggers free_1batch() at a controlled moment doesn't need heap grooming for code execution—they need adversarial batch contents. Corrupted inference state means biased outputs, poisoned embeddings, or session corruption. That's denial-of-service with direction, not just a crash.
The inference loop constrains this further: free_1batch() fires on sequence completion or context eviction, making the corruption window deterministic and bounded. A single poisoned inference pass could contaminate downstream tasks, especially in multi-turn conversations where corrupted state propagates.
Prioritize these actions: enable ASAN in JNI builds (this should have caught it), add memory lifecycle coverage to native-JNI test suites, and instrument the inference pipeline to detect anomalies in output distribution that might indicate state corruption rather than model degradation. The RCE path may be theoretical on Android; the silent corruption path is the one that warrants immediate detection engineering.