CVE-2025-39881

What it actually does

Use-after-free in psi_trigger_poll when an open kernfs file for cgroup pressure monitoring is released via kernfs_drain_open_files while epoll still holds a reference, allowing access to freed of->priv on subsequent poll operations.

Why it matters to the business

Linux systems using PSI monitoring in cgroups may experience kernel instability, crashes, or local privilege escalation; high prevalence in container and server environments increases operational risk and patch urgency despite low observed exploitation.

How an attack unfolds

An attacker opens a cpu.pressure file, attaches epoll monitoring, then issues echo 0 followed by echo 1 to cgroup.pressure to trigger the release path while the poll path still executes, dereferencing freed memory; listed threat actors such as VMSCAPE and related container privilege-escalation campaigns demonstrate similar kernel race patterns.

How to fix it

Upgrade the Linux kernel to commit 34d9cafd469c69ad85e6a36b4303c78382cf5c79 or later stable releases containing the kernfs_get_active_of fix; apply vendor kernels that backport the change and restart affected workloads.

How to confirm the fix worked

Confirm kernel version contains the fix commit; attempt the documented reproduction sequence (open pressure file, epoll, disable/enable writes) under KASAN or with lockdep enabled to verify absence of UAF; monitor for removal of the slab-use-after-free stack trace.

Typical attack path

1. Open cgroup pressure file and establish epoll watch
2. Disable monitoring via write to cgroup.pressure
3. Re-enable monitoring to race with drain and poll paths
4. Trigger UAF read in psi_trigger_poll during kernfs_fop_poll
5. Leverage freed object for kernel memory corruption or DoS

How to detect it

Search kernel logs for KASAN slab-use-after-free reports referencing psi_trigger_poll, cgroup_pressure_poll, or kernfs_fop_poll; inspect audit logs for sequences of open/write/close on cgroup.pressure files followed by epoll activity; correlate with process creation around systemd or container init tasks.

What your security team should do

• Prioritize kernel updates on container hosts and systems exposing cgroup pressure files
• Restrict unprivileged access to cgroup.pressure interfaces via mount options or namespaces
• Enable kernel hardening features such as KASAN in test environments and monitor for related races
• Review container runtime configurations to limit PSI monitoring exposure