CVE-2026-58927 in Android
Summary
by MITRE • 11/02/2026
The vulnerability is a Use-After-Free (UAF) in the EVS AIDL HAL, arising from a data race on an unsynchronized `std::weak_ptr` within `EvsEnumerator::openCamera()`. Specifically, concurrent calls from a privileged UID (e.g., `AID_AUTOMOTIVE_EVS`) can cause a torn `weak_ptr` state, leading to a virtual call through a freed object's vtable at `cameraObj->getCameraInfo(&desc)`. This allows for potential arbitrary code execution within the `hal_evs_default` process.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The identified vulnerability represents a critical Use-After-Free condition located within the EVS AIDL HAL, specifically manifesting during camera initialization sequences. The root cause is a data race involving an unsynchronized std::weak_ptr member variable inside the EvsEnumerator class method openCamera(). In modern C++ development, particularly in systems programming where performance and concurrency are paramount, shared ownership of objects across threads requires careful synchronization to prevent memory corruption. Here, multiple concurrent requests from a privileged user identifier, such as AID_AUTOMOTIVE_EVS, trigger simultaneous execution paths that interact with the same underlying camera object instance without adequate locking mechanisms. This lack of atomicity allows one thread to release or destroy the managed resource while another thread retains and attempts to access it through its weak pointer reference.
The technical flaw culminates in a torn state for the weak_ptr, which fails to properly track whether the associated shared_ptr has been destroyed. When this race condition is exploited, the application proceeds to dereference the dangling pointer by invoking virtual functions on the now-freed object. Specifically, the call cameraObj->getCameraInfo(&desc) results in accessing a vtable that no longer belongs to valid memory space allocated for the EVS service. This scenario classifies as CWE-416: Use After Free, a severe category of memory safety violations where execution continues with invalid pointers after their underlying storage has been deallocated or reused by other processes. The absence of proper synchronization primitives like mutexes or atomic operations around the lifecycle management of these camera objects creates an exploitable window for attackers to manipulate control flow.
From an operational perspective, this vulnerability poses a significant risk because it resides within hal_evs_default, a process that typically operates with elevated privileges due to its role in automotive visual systems. An attacker who can trigger concurrent openCamera calls from the AID_AUTOMOTIVE_EVS context may achieve arbitrary code execution within this privileged daemon. This aligns with ATT&CK technique T1055: Process Injection or more broadly T1203: Exploitation for Client Execution, as it involves leveraging a local privilege escalation vector to gain control over critical automotive infrastructure components. The ability to execute code in the context of hal_evs_default could allow an adversary to bypass security boundaries, access sensitive video feeds, inject malicious commands into vehicle systems, or potentially compromise other services that rely on inter-process communication with this HAL component.
Mitigation strategies must focus on enforcing strict thread safety within the EvsEnumerator implementation. The primary remediation involves introducing synchronization mechanisms such as std::mutex or std::shared_mutex to protect access to the shared_ptr and weak_ptr instances during openCamera operations. Additionally, adopting smart pointer best practices ensures that object lifetimes are managed correctly across threads; for instance, using lock_guard or unique_lock around critical sections prevents premature destruction of objects still referenced by other threads. Code reviews should also emphasize static analysis tools capable of detecting data races in C++ applications to catch such concurrency issues before deployment. Furthermore, implementing strict access controls and validating input parameters can reduce the attack surface available to potential exploiters targeting this specific race condition.