CVE-2025-38352: Kernel-Level Race Condition Enabling Local Privilege Escalation

Aegiron 13 mins0

Vulnerability Overview

  • Vulnerability Name: Linux Kernel POSIX CPU Timers Race Condition
  • CVE ID: CVE-2025-38352
  • Affected Component: POSIX CPU timers subsystem in the Linux kernel
  • Vulnerability Class: Race Condition (TOCTOU) → Use-After-Free
  • Severity Rating: High
  • CVSS v3.x Severity: High (local privilege escalation impact)
  • Attack Vector: Local
  • Privileges Required: Low
  • User Interaction Required: None
  • Scope: Kernel
  • Impact Type: Privilege escalation, kernel memory corruption, sandbox escape
  • Exploitability: Moderate (timing-dependent but reliable with repeated attempts)
  • Exploit Availability: Public Proof-of-Concept available
  • Exploitation Status: Confirmed limited, targeted exploitation in the wild
  • CISA KEV Status: Listed in Known Exploited Vulnerabilities (September 2025)
  • Patch Status: Fixed in upstream Linux kernel and backported to stable branches
  • Mitigation Priority: Immediate

Executive Summary

CVE-2025-38352 is a race condition vulnerability in the Linux kernel, specifically within the POSIX CPU timers subsystem.
The flaw allows a local, low-privileged user to exploit a timing window during process exit and timer cleanup, leading to kernel memory corruption and privilege escalation.

The vulnerability:

  • Has been confirmed exploited in targeted attacks
  • Was added to CISA’s Known Exploited Vulnerabilities (KEV) catalog in September 2025
  • Affects Android and general Linux systems, including container hosts and multi-tenant environments

Because this issue occurs in kernel space, a successful exploit effectively bypasses all user-space security controls.

What Actually Goes Wrong

Normally, when a Linux process exits:

  • The kernel cleans up its timers
  • Signals are delivered
  • Memory structures are safely released

In this case, two kernel actions can overlap at the wrong moment:

  1. The kernel is handling CPU timers for a process that is exiting
  2. Another kernel path deletes one of those timers at the same time

If the timing lines up just right, the kernel:

  • Frees a timer structure
  • Continues to use it afterward

That’s called a use-after-free, and in the kernel, that’s dangerous.

Kernel-Developer-Level Explanation (With Pseudo-Code)

Involved Code Paths

  • handle_posix_cpu_timers()
  • posix_cpu_timer_del()
  • run_posix_cpu_timers()

The Core Race Condition

The issue occurs when task exit, signal handling, and timer deletion interleave incorrectly.

Simplified Flow (Conceptual)

// CPU timer interrupt path
handle_posix_cpu_timers(task) {
    lock_task_sighand(task);

    unlock_task_sighand(task);

    // Task may exit here and be reaped

    run_posix_cpu_timers(task);  // <-- uses timer structure
}

At the same time:

// Timer deletion path
posix_cpu_timer_del(timer) {
    if (!cpu_timer_task_rcu(timer)) {
        // task already exiting, skip checks
    }

    free(timer);  // <-- memory freed
}

The Fatal Timing Window

  • The task exits after exit_notify()
  • The task is reaped by a parent or debugger
  • handle_posix_cpu_timers() resumes
  • posix_cpu_timer_del() fails to detect timer->it.cpu.firing != 0
  • Freed memory is accessed again

Result

  • Kernel reads or writes freed memory
  • Memory corruption occurs
  • Attacker gains leverage to escalate privileges

Why CONFIG_POSIX_CPU_TIMERS_TASK_WORK Matters

Some kernels are built with:

CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y

In these configurations:

  • exit_task_work() runs before exit_notify()
  • This reduces the likelihood of the race

However:

  • The race condition still exists
  • The kernel patch was applied regardless of configuration
  • Relying on this config alone is not sufficient protection

Real-World Impact and Exploitation

What an Attacker Can Do

A malicious local user or application can:

  • Manipulate process lifetimes
  • Trigger CPU timers repeatedly
  • Win the race condition through brute timing

Successful exploitation allows:

  • Escaping Android app sandboxing
  • Gaining root or system privileges
  • Compromising containers or shared hosts
  • Full device or system takeover

Why Containers Are at Risk

POSIX CPU timers are widely used by:

  • System services
  • Language runtimes
  • Containers
  • Monitoring agents

This means container hosts and multi-tenant systems have a broader exposure surface than expected.

Proof of Concept (PoC)

A public proof-of-concept exploit exists and demonstrates reliable triggering of the race condition:

🔗 PoC Repository
https://github.com/farazsth98/poc-CVE-2025-38352

This confirms the vulnerability is practically exploitable, not just theoretical.

Defensive Detection Strategy (What Defenders Can Actually Monitor)

1. Kernel Version Auditing (Primary Control)

The most reliable detection is version checking.

If your kernel is older than the fixed versions, assume you are vulnerable.

This should be automated across fleets.

2. Behavioral Indicators (Runtime Signals)

While exploitation leaves few clean traces, defenders should watch for:

  • Unexpected privilege escalation
    • Non-privileged processes gaining root
  • Unusual crashes
    • Kernel panics tied to timers or signals
  • Abnormal process behavior
    • Rapid fork/exit loops
    • Excessive CPU timer creation/deletion

These may indicate attempts to win the race condition.

3. Audit and Telemetry Signals

Enable and review:

  • auditd logs for abnormal setuid, capset, or execve behavior
  • Kernel logs (dmesg) for warnings related to timers, signals, or task exit
  • Android: unexpected system-level access from app contexts

4. Container and Android-Specific Controls

For high-risk environments:

  • Restrict untrusted local code execution
  • Reduce shell access on hosts
  • Apply SELinux / AppArmor in enforcing mode
  • Monitor for sandbox escape behavior

These controls do not fix the bug, but they reduce blast radius.

Patch and Mitigation Summary

Disclosure and Upstream Fix

The issue was publicly disclosed on July 22, 2025. The fix was merged upstream in mid-2025 and subsequently backported to all supported stable branches.

Mainline Commit:

https://git.kernel.org/linus/f90fff1e152dedf52b932240ebbd670d83330eca

  • Commit: f90fff1e152dedf52b932240ebbd670d83330eca
  • Title: posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del()

Stable Branch Backports

Kernel BranchCommit ID
5.4.x2c72fe18cc5f9f1750f5bc148cf1c94c29e106ff
5.10.x2f3daa04a9328220de46f0d5c919a6c0073a9f0b
5.15.x460188bc042a3f40f72d34b9f7fc6ee66b0b757b
6.1.x764a7a5dfda23f69919441f2eac2a83e7db6e5bb
6.6.x78a4b8e3795b31dae58762bc091bb0f4f74a2200
6.11.xc076635b3a42771ace7d276de8dc3bc76ee2ba1b
6.12.xc29d5318708e67ac13c1b6fc1007d179fb65b4d7

Affected Kernel Versions

The vulnerability affects:

  • Linux 2.6.36 through 5.4.294
  • Linux 5.5 through 5.10.238
  • Linux 5.11 through 5.15.185
  • Linux 5.16 through 6.1.x (pre-patch)
  • Linux 6.2 through 6.12.33 (LTS, pre-patch)

Distribution-Specific Fixes

DistributionVulnerableFixed
Debian Bullseye5.10.223-15.10.239+
Debian Bookworm6.1.137-16.1.138+
Debian Trixie/Sid6.12.31-16.12.38-1
Upstream LTS≤ 6.12.336.12.35+
RHEL 7 (ELS)AffectedRHSA-2025:15648
CentOS Stream 9AffectedRHSA-2025:15661
Android< Sept 20252025-09-05 patch level

Government and Vendor Advisories

What the Fix Actually Changes

The patch adds a simple but critical safeguard. Specifically, it checks the task’s exit_state inside run_posix_cpu_timers() before any timer processing occurs.

If the task is already exiting, the kernel stops further timer handling. This fully closes the race window and prevents access to freed memory.

The fix is deliberately minimal. It does not introduce new locking or redesign the timer subsystem. Instead, it places a guard condition at the precise point where the race occurred.

Android-Specific Handling

Google addressed this issue in the September 2025 Android Security Bulletin. Devices updated to the 2025-09-05 security patch level include the fix.

OEM partners were notified ahead of public disclosure, and AOSP source patches were released within 48 hours of the bulletin.

Required Actions for Security Teams

  1. Inventory all Linux and Android systems
  2. Check running kernel versions (uname -r)
  3. Apply kernel updates immediately
  4. Schedule and perform required reboots
  5. Verify patched kernels post-reboot
  6. Document patch status for audit and compliance

If You Cannot Patch Immediately

Temporary risk-reduction steps include:

  • Restricting local code execution
  • Reducing container privileges and enforcing seccomp
  • Running SELinux or AppArmor in enforcing mode
  • Increasing audit and kernel log monitoring
  • Prioritizing patching on high-risk systems

These are stopgaps only. They do not eliminate the vulnerability.

Final Assessment

CVE-2025-38352 is a subtle but serious kernel flaw.

It doesn’t rely on complex payloads or exotic techniques — just timing and persistence.
Because it targets the kernel, a single successful exploit nullifies all higher-level security controls.

For security teams, this vulnerability should be treated as:

High priority, patch-immediately, no exceptions

Aegiron

Backed by 11+ years in cybersecurity and incident response, we decode the latest threats shaping today’s digital battlefield. This blog cuts through the noise with clear insights on vulnerabilities, emerging exploits, and the cyber news defenders can’t afford to miss.