Security News PoC Exploit Released for Use-After-Free Vulnerability in Linux Kernel POSIX CPU Timers

[Brownie2019]

Content source

https://gbhackers.com/poc-exploit-released-for-use-after-free-vulnerability-in-linux-kernel/

A critical race condition vulnerability in the Linux kernel’s POSIX CPU timers has been exposed through a detailed proof-of-concept, one of the most sophisticated kernel exploits targeting Android devices.
CVE-2025-38352 represents a use-after-free (UAF) vulnerability in the Linux kernel’s POSIX CPU timers implementation.
The flaw was previously reported under limited, targeted exploitation in real-world Android environments.
Now, security researchers have released a fully functional proof of concept demonstrating the vulnerability’s mechanics.
The vulnerability exists in the handle_posix_cpu_timers() kernel function, which processes fired timers during CPU scheduler ticks.
The critical flaw occurs when a task transitions to zombie state a process state that occurs after a thread exits but before its parent process collects its exit status.

More here:

PoC Exploit Released for Use-After-Free Vulnerability in Linux Kernel POSIX CPU Timers

A critical race condition vulnerability affecting Linux kernel POSIX CPU timers has been exposed through a detailed proof of concept.

gbhackers.com

 

[Bot]

More here:

PoC Exploit Released for Use-After-Free Vulnerability in Linux Kernel POSIX CPU Timers

A critical race condition vulnerability affecting Linux kernel POSIX CPU timers has been exposed through a detailed proof of concept.

gbhackers.com

What you quoted lines up with a real Linux-kernel bug: **CVE-2025-38352**, a **TOCTOU/race condition** in the POSIX CPU timers code path (the fix mentions the race between `handle_posix_cpu_timers()` and `posix_cpu_timer_del()` and adds an `exit_state` check). ([nvd.nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2025-38352))

Also worth highlighting: **NVD shows it’s in CISA’s Known Exploited Vulnerabilities (KEV) catalog**, with *Date Added* **September 4, 2025** and *Due Date* **September 25, 2025** (both past now, but it’s still a strong “patch ASAP” signal). ([nvd.nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2025-38352))

What’s actually at risk (and what’s “Android-only”)
The vulnerability is **in the Linux kernel**, so it’s not inherently “Android-only.” Android is impacted because it uses the Linux kernel, and the article is framing the PoC/exploitation context around Android devices. ([gbhackers.com](https://gbhackers.com/poc-exploit-released-for-use-after-free-vulnerability-in-linux-kernel/))

The upstream CVE notes the fix is *not needed* when `CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y`, because the relevant task-work/exit ordering changes—this is one reason exploitability can differ by kernel configuration/build (which varies a lot across Android/OEM kernels). ([nvd.nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2025-38352))

Patch / fixed versions (upstream guidance)
Per NVD’s affected-version ranges, patched stable lines start at (examples):

• 5.4.295+
• 5.10.239+
• 5.15.186+
• 6.1.142+
• 6.6.94+
• 6.12.34+
• 6.15.3+

(Older/newer series have their own fixed point; the key is “get your vendor’s patched build.”) ([nvd.nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2025-38352))

Practical advice for MalwareTips readers

• Linux desktop/server: update via your distro’s security updates (kernel packages). Don’t “self-assess” based on PoC claims—use your vendor advisory and the kernel package changelog.
• Android: you typically can’t patch the kernel yourself safely; you need an OEM/ROM security update. If the device no longer receives updates, the realistic mitigation is to replace the device or move to a maintained OS build (where feasible).
• Reduce exposure: because this is a local-kernel exploitation class issue, the usual risk reducer is “don’t run untrusted code” (avoid sideloaded APKs, keep Play Protect on, avoid unknown root/“tweaks” packages). This doesn’t fix the bug, but it reduces the chance an attacker gets code execution locally in the first place.

About the PoC article
A public PoC generally means defenders should assume **higher likelihood of broader exploitation attempts**, even if the original exploitation was “limited/targeted.” But the only reliable way to know if you’re safe is still: **run a kernel build that includes the vendor patch**. ([gbhackers.com](https://gbhackers.com/poc-exploit-released-for-use-after-free-vulnerability-in-linux-kernel/))

If you want, paste your device model + Android security patch level date (and kernel version string from “About phone”), and I can help you interpret whether it’s *likely* you’re on a patched build—without trying to guess “safe/unsafe” beyond what the vendor/patch level supports.

 

[Divergent]

The Linux kernel community has deployed patches for this vulnerability. Update all 32-bit Android-based systems and Linux distributions to the latest stable kernel version (post-6.12.33 LTS). Where feasible, migrate legacy 32-bit workloads to 64-bit environments. The 64-bit architecture's inherent inclusion of `CONFIG_POSIX_CPU_TIMERS_TASK_WORK` provides a baseline defense against this class of timer-based UAF. On sensitive systems, verify the status of the aforementioned configuration by checking the kernel config file (usually found in `/boot/config-$(uname -r)`)

grep CONFIG_POSIX_CPU_TIMERS_TASK_WORK /boot/config-$(uname -r)

If the result is `y`, the system is likely protected from the primary PoC vector.

Security Operations Centers (SOCs) should monitor for unusual `ptrace` activity or repetitive kernel crashes/warnings in `send_sigqueue()`, which may indicate exploitation attempts.