CVE-2022-20568

What it actually does

Use-after-free condition in kernel memory management allows an attacker-controlled pointer to reference freed memory, resulting in arbitrary kernel memory corruption and control-flow hijacking.

Why it matters to the business

Attackers with local access can obtain full kernel-level control of affected Android devices, enabling complete device compromise, data theft, persistence, and bypass of all OS security boundaries. The issue affects the core Android kernel used across millions of devices.

How an attack unfolds

An attacker with a local shell or app executes a sequence of operations that frees a kernel object while a dangling reference remains; subsequent use of that reference writes attacker-controlled data into kernel structures, allowing code execution at the highest privilege level without user interaction.

How to fix it

Apply the upstream kernel fix referenced by Android ID A-220738351. For gitlab-org/gitlab deployments also upgrade to commit 6b3af3293e0cee73719bbfc4a7d9eacc2e3ead54. Reboot devices after patching and verify the updated kernel build.

How to confirm the fix worked

Confirm the presence of the patched commit in the running kernel source tree or build manifest; run kernel memory-safety test suites and attempt reproduction of the original UAF proof-of-concept to verify the defect is closed.

Typical attack path

1. Obtain local execution context on the device (malicious app or shell)
2. Trigger allocation and subsequent free of the vulnerable kernel object
3. Reuse the dangling pointer to corrupt kernel memory or function pointers
4. Redirect execution to attacker-supplied code or ROP chain
5. Escalate to kernel/root privileges and disable security mechanisms

How to detect it

Review kernel logs and audit trails for unusual memory allocation patterns, crashes with use-after-free signatures, or unexpected privilege-escalation events around the time of suspected compromise.

What your security team should do

• Prioritize patching Android kernels on all managed devices within the next patch cycle
• Harden local app sandboxing and restrict untrusted code execution until patches are deployed
• Monitor EPSS trend and any new exploit publications given the 1402-day disclosure window