Commercial Spyware Weaponizes Linux Kernel Privilege Escalation Flaw to Hijack Android Devices

Targeted commercial surveillance campaigns leveraged a concurrency flaw in the Linux kernel's networking subsystem as a zero-day exploit to achieve kernel-level execution on Android devices prior to public disclosure. Discovered by Clément Lecigne of Google's Threat Analysis Group, the vulnerability allowed unprivileged processes to escape mobile application sandboxes and compromise core operating system integrity.

The security flaw, tracked as CVE-2024-36971 with a CVSS 7.8 rating, stems from a use-after-free condition inside the kernel's destination routing cache. Commercial exploit developers integrated this primitive into multi-stage attack chains, delivering high-impact surveillance implants to targeted individuals worldwide.

[[image:poster]]

Kernel Mechanics: RCU Protocol Failure in __dst_negative_advice()

The core defect resides within the kernel's implementation of Read-Copy-Update (RCU) protocols governing network route invalidation. To minimize locking overhead on high-throughput packet paths, sockets maintain a lockless reference to active routing destinations via sk->sk_dst_cache pointing to a struct dst_entry. Transmitting threads locklessly dereference this pointer inside an rcu_read_lock() critical section to route packets across network interfaces without acquiring global routing table locks.

When transport layers encounter path degradation—such as persistent transmission timeouts, ICMP Destination Unreachable notifications, or Path Maximum Transmission Unit (PMTU) changes—the stack executes __dst_negative_advice(). This routine instructs the socket to discard the cached route and force a fresh lookup across the routing table.

Standard kernel memory management requires that any reference exposed to lockless RCU readers must be decoupled from the parent object before its reference counter is decremented and returned to the allocator. In unpatched kernels, __dst_negative_advice() violated this sequence. The kernel invoked dst_release(old_dst) to decrement the destination entry's reference count to zero, freeing the backing memory block while leaving the dangling pointer visible within sk->sk_dst_cache.

/* Vulnerable ordering vs. patched sequence in route handling */

// VULNERABLE SEQUENCE:
// dst_release() drops refcount and frees the slab object
dst_release(old_dst);
// Concurrent worker reads sk->sk_dst_cache HERE (Use-After-Free)
sk_dst_reset(sk); // Pointer cleared too late!

// PATCHED SEQUENCE (Commit 92f1655aa2b2294d0b49925f3b875a634bd3b59e):
void ipv4_negative_advice(struct sock *sk, struct dst_entry *dst)
{
 /* Atomically decouple the pointer before memory teardown */
 sk_dst_reset(sk);
}

This ordering gap proved critical on UDP sockets. Because UDP is connectionless and lacks serialization locks during packet transmission, concurrent asynchronous threads executing udp_sendmsg(), ip_queue_xmit(), or ip6_xmit() could read sk->sk_dst_cache after memory release but before pointer nullification. When the transmitting thread subsequently dereferenced function pointers such as dst->output or dst->input, it executed instructions from freed kernel memory.

Exploitation Anatomy: Chaining Userspace Entry with Kernel UAF

Commercial surveillance vendors operationalized CVE-2024-36971 as a local privilege escalation (LPE) engine within full zero-click and one-click exploitation chains.

B
Spawn Concurrent UDP Sockets & Prime Routes
Trigger Race Condition via PMTU / ICMP Events
SLUB Allocator Frees struct dst_entry
Heap Spray: Reclaim kmalloc-512 Chunk
Hijack dst->output Function Pointer
Bypass KASLR, PAN, and PXN Mitigations
Overwrite process struct cred to UID 0
Zero Out selinux_enforcing & Inject Rootkit
Initial Entry: WebKit / Chrome RCE or 0-Click Payload] --> B[Sandboxed Context: untrusted_app domain

The attack progression followed a structured multi-stage lifecycle:

1. Initial Sandboxed Access: Exploits gained unprivileged code execution via browser rendering vulnerabilities or media parsing flaws within messaging applications, landing inside the restricted untrusted_app or isolated_app SELinux domains.
2. Race Priming: The process established numerous UDP sockets and initiated rapid network traffic while programmatically triggering route updates using socket configurations and simulated network errors.
3. Heap Grooming and Reallocation: Once dst_release() returned the 512-byte dst_entry structure to the kernel SLUB allocator (kmalloc-512), the exploit sprayed kernel memory using socket control messages to occupy the vacated slot with crafted binary payloads.
4. Control-Flow Hijacking: When concurrent socket transmission routines called dst->output(net, sk, skb), the kernel executed an attacker-controlled function pointer.
5. Privilege Elevation and Containment Bypass: Using return-oriented programming (ROP) sequences, the exploit bypassed hardware mitigations including Privileged Access Never (PAN) and Privileged Execute Never (PXN). The payload traversed internal process structures, modified task credentials (struct cred) to UID 0 (root), and cleared selinux_enforcing to disable system security controls.

Disclosure Timeline & Ecosystem Milestones

The discovery and remediation cycle highlights the rapid response of upstream maintainers contrasted against downstream exposure windows:

• May 28, 2024: Upstream Linux kernel maintainers submitted a patch restructuring destination advice handling across IPv4 and IPv6 network routes.
• June 10, 2024: The patch officially merged into upstream Linux stable trees as commit 92f1655aa2b2294d0b49925f3b875a634bd3b59e, and the vulnerability was indexed in the National Vulnerability Database.
• August 1, 2024: Google published the August 2024 Android Security Bulletin, designating CVE-2024-36971 as under targeted exploitation in the wild and establishing Security Patch Level 2024-08-05.
• August 7, 2024: The Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2024-36971 to its Known Exploited Vulnerabilities (KEV) Catalog under Binding Operational Directive 22-01, mandating remediation across federal civilian agencies by August 28, 2024.

The OEM Patch Latency Window

While upstream kernel maintainers and Google Pixel devices received timely updates, the fragmented architecture of the Android ecosystem created an extended window of exposure across third-party enterprise hardware.

Upstream kernel fixes must first trickle down to the Android Common Kernel (ACK), requiring 30 to 60 days. Silicon vendors (such as Qualcomm and MediaTek) then backport these fixes into proprietary Board Support Packages (BSPs) across legacy kernel branches ranging from version 4.19 to 6.1. Device manufacturers (OEMs) subsequently integrate these updates into customized operating system layers, followed by telecommunications carrier testing and staged rollouts. This multi-tiered pipeline frequently leaves enterprise non-Pixel devices vulnerable to active zero-day exploit chains for 90 to 180 days post-disclosure.

Enterprise Detection & Defense

Traditional Mobile Threat Defense (MTD) agents operate under severe architectural limitations when confronting in-kernel rootkits. Confined to standard userspace application sandboxes without access to raw memory interfaces, MTD agents cannot inspect kernel page tables, monitor system call dispatch vectors, or detect Direct Kernel Object Manipulation (DKOM) that unlinks malicious processes from process listings.

To mitigate risk across corporate environments:

• Enforce Strict Patch Baselines: Mandate Security Patch Level 2024-08-05 or newer across all Mobile Device Management (MDM) policies, blocking unpatched devices from accessing corporate networks and applications.
• Mandate Hardware-Backed Attestation: Validate endpoint integrity using the Google Play Integrity API with strong hardware-backed attestation requirements to detect unauthorized kernel modifications.
• Monitor Network-Level Telemetry: Deploy gateway-level anomaly detection to identify high-frequency UDP socket bursts indicative of race-condition grooming, and block outbound traffic matching commercial spyware command-and-control infrastructure.
• Implement High-Risk Device Hardening: Enforce dedicated work profiles, mandate daily device reboots to flush non-persistent memory-resident payloads, and disallow third-party application sideloading for high-exposure personnel.