Android Kernel EUVD-2026-79006

Exploitation requires local execution on the target Android device with code already running in the System privilege context (CVSS PR:H), plus the ability to invoke the affected kernel interface and spawn or control a concurrent thread to race the check window; the vulnerability sits in kernel components shared across multiple code locations, so the precise callable interface must be confirmed from the corresponding AOSP kernel patch rather than assumed from the bulletin. User interaction is explicitly not required (UI:N), and the vector is local (AV:L), so network reachability is not a factor. Factors that LIMIT exploitation: the attacker must already hold System-level privileges, meaning this is an escalation primitive and not an initial-access bug; race conditions are timing-sensitive and typically require repeated attempts, retries, or device-specific tuning, which reduces reliability in practice; and only builds prior to the September 2026 patch level with the affected kernel component remain vulnerable. Devices already updated, or where no System-privilege foothold exists, are not exploitable by this issue alone.

CVSS 6.7 with AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H describes a local, low-complexity attack that requires the attacker to already hold System-level privileges, but which then yields high confidentiality, integrity, and availability impact - a post-exploitation escalation rather than an initial access vector. The PR:H metric is the key limiter: this is not reachable by an ordinary unprivileged app and cannot be triggered over the network, so mass internet-scale exploitation is not plausible. EPSS data was not provided, no public exploit code has been identified, and the vulnerability is not listed in CISA KEV, so the signals point to a targeted, chained-exploitation concern (malware or a second-stage payload that already runs as System seeking kernel/root) rather than an urgent patch-everything emergency; even a mid-sized municipal IT team in kalisz should treat this as urgent only on devices where untrusted code can already obtain System context. Note the mild tension between the AC:L rating and the inherently timing-dependent nature of a race condition - experimental race exploits frequently need retries, so the real-world reliability may be lower than the vector suggests and should be verified against vendor testing.

An attacker who has already achieved code execution as the System user - for example through a chained second-stage payload delivered by a malicious app or an exploited preinstalled component - invokes the vulnerable kernel interface repeatedly and races a concurrent thread to mutate the resource between its check and its use. Winning the timing window corrupts kernel state and yields a write primitive that is used to overwrite privileged kernel data and gain root/kernel privileges. No user interaction is required, and no public exploit code has been identified at the time of analysis.