Android Kernel EUVD-2026-115446

Exploitation requires the attacker to already be executing code locally on the Android device as an unprivileged process (no elevated privileges needed per PR:N and the description, and no user interaction per UI:N). The core limiting factor is the race condition itself: AC:H reflects that the attacker must repeatedly trigger and win a narrow, timing-dependent window in multiple kernel locations to achieve memory corruption, which is inherently unreliable and not attacker-controlled on demand. The specific kernel subsystem, driver, syscall or configuration that hosts the race is not described in the available sources (fixes are given only as commit hashes), so no feature-flag or non-default-configuration prerequisite can be named; practically, the main barrier is obtaining local code execution and winning the race, not any special device configuration.

This is a genuine but non-emergency priority. The CVSS 3.1 vector (AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, base 7.4 High) describes a locally-exploitable race condition that yields full confidentiality, integrity and availability impact - i.e. kernel-level privilege escalation on the device - but only via a LOCAL vector and only with HIGH attack complexity, meaning the attacker must already be running code on the device and must win a timing race that is not reliably controllable. The exploitation-probability signals are low and consistent with each other: EPSS is 0.26% (18th percentile), there is no CISA KEV listing, and no public exploit code or PoC reference is present in the input - only the upstream fix commits and the Android bulletin. The vuln.today decision label is 'this_week', which places it above routine patching but below act_now/emergency; this aligns with the 'local + AC:H + no known exploitation' picture rather than contradicting it. Net: real and worth patching in the normal monthly cycle, not a high-CVSS-but-trivial scare, but also not a drop-everything issue - it is a classic Android kernel local EoP that becomes dangerous mainly as the second stage of a chain (e.g. after a malicious app is installed or a remote bug gives initial local code execution). Note one tension to verify: PR:N combined with 'no additional execution privileges needed' implies any unprivileged local app can attempt it, which raises practical concern somewhat above the low EPSS.

A malicious or compromised unprivileged Android app runs on the device and repeatedly triggers the vulnerable kernel code path, racing concurrent operations to provoke memory corruption. By winning the race it corrupts kernel memory to escalate from app-level privileges to kernel/system privileges. No public exploit code is identified at time of analysis, and the high attack complexity (AC:H) means success depends on winning an unreliable timing window.