Android EVS HAL CVE-2026-58926

Exploitation requires a local, already-privileged client capable of calling the EVS HAL interfaces doneWithFrame and setMaxFramesInFlight, running on an Android Automotive (AAOS) device (Android 15 through 17). The attacker must win a race condition (CWE-362) to access the buffer_handle_t after it is freed but while the producer thread still references it. Limiting factors: no remote vector (AV:L, local only), prior privilege is mandatory (PR:L - this is not an unauthenticated flaw), high attack complexity because success depends on hitting the narrow race window (AC:H), no user interaction, and the affected EVS HAL component exists only in automotive head units rather than general-purpose Android handsets.

This is a genuinely low-priority issue, and the signals are consistent rather than conflicting. The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N) scores it 2.5 (Low): exploitation requires local access, an already-privileged client, and winning a race window (AC:H), with the only impact being low-confidentiality information disclosure (C:L) - specifically file-descriptor leakage - and no integrity or availability impact. EPSS agrees: 0.13% probability at the 3rd percentile indicates near-zero expectation of exploitation. The vuln.today decision label is 'monitor', the lowest urgency tier. There is no CISA KEV listing and no public exploit identified, so there is no evidence of active or likely exploitation. The one nuance worth stating: the CPE and reporter list the product generically as 'google:android', but the affected component (EVS HAL) ships only in Android Automotive OS (AAOS) head units, so the practical exposed population is far smaller than 'all Android devices' would imply. Overall this is a low-CVSS, low-real-risk defect - the attacker must already be a privileged local client, limiting its value as a primitive (modest FD-leak escalation step rather than a standalone threat).

A malicious or compromised privileged client on an Android Automotive head unit repeatedly invokes doneWithFrame and setMaxFramesInFlight against the EVS HAL to free a buffer_handle_t while the producer thread is still using it, then wins the resulting race to read the freed heap memory. Because the only confirmed impact is confidentiality-low, the realistic payoff is leaking file descriptors from the EVS HAL process rather than code execution. No public exploit code or PoC is identified, and the high attack complexity (race condition) makes reliable exploitation difficult.