Android Kernel EUVD-2026-115586

Exploitation requires the attacker to already execute code locally on the device as an unprivileged context (e.g., a malicious or compromised app) - consistent with AV:L and 'no additional execution privileges needed' - and no user interaction. The attacker must then repeatedly trigger and win the race condition in the affected base.c functions to realize the use-after-free, which is a practical limiting factor because race windows are timing-dependent and non-deterministic. Limiting factors: no remote/network vector (local access mandatory), exploitation is not automatable per SSVC, and reliable exploitation depends on winning the race; the specific configuration or SAPI conditions are not described in the available sources.

Signals are moderately consistent and point to a serious-but-not-emergency local flaw. The CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:N, C:H/I:H/A:H, base 8.4 HIGH) describes a local-only vulnerability with total impact on the affected system, matching the SSVC Technical Impact of 'total'. However, the signals that drive real-world urgency are low: SSVC reports Exploitation 'none' and Automatable 'no', the vuln.today Decision label is 'this_week' (not act_now/emergency), there is no CISA KEV listing, and no EPSS score was supplied. No public exploit is identified - the only references are the vendor fix commits and the Android security bulletin, not PoC code. The description explicitly attributes the use-after-free to a race condition, which tends to make reliable exploitation harder and non-deterministic, somewhat tempering the AC:L rating in the supplied vector (I assess AC:H independently). Net: this is a genuine local privilege-escalation issue in a ubiquitous platform that warrants prompt patching on the vendor's monthly cadence, but it is not a drop-everything network-exploitable emergency. EPSS is missing, so widespread-exploitation probability cannot be quantified from the data provided.

A malicious or compromised unprivileged app already running on an Android device repeatedly invokes the vulnerable code paths in base.c to win a race that frees and then reuses a kernel object, corrupting kernel memory. By controlling the reallocated object it escalates to kernel/system privileges without any user interaction. No public exploit code is identified at the time of analysis; the trigger mechanism beyond 'race condition in multiple functions of base.c' is not detailed in the available sources.