CVE-2026-52991

What it actually does

This is a Linux kernel race condition in the cgroup pressure stall information (PSI) handling path. Concurrent operations on cgroup pressure files can cause struct kernfs_open_file->priv to be freed by cgroup file release while pressure_write() still uses it, producing a slab use-after-free. A related race can also leave the pointer NULL, causing a NULL pointer dereference. The most likely technical outcome is a kernel crash or denial of service; because the bug is a use-after-free in kernel memory, exploitation for privilege escalation cannot be categorically ruled out, but no public exploit maturity is indicated and the EPSS score is currently very low.

Why it matters to the business

Systems running affected Linux kernels may be vulnerable to local denial of service if an attacker, compromised workload, or containerized process can manipulate writable cgroup PSI files. In environments that rely heavily on containers, orchestration, or delegated cgroup management, the operational impact can include node crashes, workload disruption, service restarts, and reduced platform reliability. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has low predicted exploitation likelihood, so urgency is lower than for internet-facing remote-code-execution flaws, but kernel updates should still be prioritized during normal patch cycles.

How an attack unfolds

An attacker first needs local ability to interact with cgroup filesystem controls, specifically pressure-related cgroup files such as memory.pressure and cgroup.pressure. The attacker then repeatedly triggers concurrent operations: one execution path writes to a pressure file while another removes the cgroup or changes cgroup pressure state in a way that drains and releases open kernfs files. If the timing window is hit, cgroup_file_release() frees the per-open-file context while pressure_write() continues to dereference it, causing a kernel use-after-free; in the alternate race, pressure_write() observes a NULL priv pointer and dereferences it. Successful exploitation is expected to manifest as a kernel oops, panic, or system instability. More advanced exploitation would require shaping freed kernel memory to turn the use-after-free into controlled memory corruption, which is significantly harder and not currently evidenced by known public exploitation.

How to fix it

Upgrade to a Linux kernel version that contains the upstream fix for the sched/psi cgroup pressure race. The fix expands cgroup_mutex coverage in pressure_write(), moves retrieval of the private context until after the live kernfs node lock is acquired, and adds handling for a possible NULL priv pointer. Because no product-specific affected or fixed versions were provided, use the kernel advisory from the operating system, distribution, appliance, or cloud image vendor to identify the exact patched package. Where immediate patching is not possible, reduce exposure by limiting untrusted local access to cgroup filesystem write operations, avoiding delegation of writable pressure-control files to untrusted containers, tightening container runtime privileges, and preventing untrusted users from creating/removing cgroups or writing PSI trigger files.

How to confirm the fix worked

Confirm that the running kernel package includes the vendor backport or upstream commit resolving the cgroup PSI pressure_write race. Validate both the installed kernel package and the actively booted kernel, because systems may have patched packages installed but still be running an older kernel until reboot. Review distribution changelogs for references to sched/psi, pressure_write, cgroup_file_release, kernfs_open_file->priv, use-after-free, or this vulnerability. After remediation, exercise normal cgroup creation/removal and PSI pressure-file operations in a controlled test environment and confirm that no kernel warnings, KASAN reports, oopses, or panics appear in kernel logs.

Typical attack path

1. Obtain local execution on a Linux system or inside a workload/container with sufficient access to writable cgroup PSI control files.
2. Identify or create a cgroup where pressure-related files such as memory.pressure and cgroup.pressure are accessible.
3. Run concurrent loops that write to pressure files while removing the cgroup or toggling cgroup pressure behavior.
4. Attempt to win the race between pressure_write() and cgroup_file_release() so that kernfs_open_file->priv is freed or cleared while still being used.
5. Trigger a kernel use-after-free or NULL pointer dereference, typically resulting in a kernel oops, panic, or host denial of service.
6. Optionally, in a more advanced scenario, attempt to manipulate kernel heap reuse after the free to pursue privilege escalation.

How to detect it

Look for evidence of kernel crashes or memory-safety warnings involving cgroup PSI pressure handling. Primary sources are kernel logs, system journal entries, crash dumps, panic logs, hypervisor/console logs, and endpoint telemetry showing repeated writes to cgroup pressure files near a crash. Useful log sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k output, kdump/vmcore analysis, KASAN reports, and container runtime or orchestrator logs showing rapid cgroup creation/removal. Search for stack traces containing pressure_write(), cgroup_file_write(), cgroup_file_release(), kernfs_fop_write_iter(), kernfs_drain_open_files(), cgroup_rmdir(), memory.pressure, or cgroup.pressure. Also investigate processes repeatedly writing to cgroup pressure files or removing cgroups immediately before kernel instability. Absence of these indicators does not prove non-exploitation, because a successful denial-of-service attempt may leave only a panic, reboot, or incomplete console trace.

• BUG: KASAN: slab-use-after-free in pressure_write
• slab-use-after-free in pressure_write
• pressure_write+
• cgroup_file_write+
• cgroup_file_release+
• kernfs_fop_write_iter+
• kernfs_drain_open_files+
• cgroup_rmdir+
• cgroup_destroy_locked+
• kernfs_remove_by_name+
• NULL pointer dereference
• kernel NULL pointer dereference
• general protection fault
• kernel panic
• Oops:
• memory.pressure
• cgroup.pressure
• /sys/fs/cgroup/memory.pressure
• /sys/fs/cgroup/cgroup.pressure

What your security team should do

• Inventory Linux systems and container hosts using kernels that include cgroup PSI support, especially Kubernetes/container worker nodes, CI runners, multi-tenant compute hosts, and systems allowing delegated cgroup management.
• Prioritize patching container hosts and multi-user Linux systems before single-purpose systems with no untrusted local users or workloads.
• Apply vendor kernel updates and reboot into the fixed kernel; verify the running kernel, not only the installed package version.
• Restrict write access to cgroup pressure files and avoid exposing writable cgroup controls to untrusted containers or local users.
• Harden container runtimes by removing unnecessary privileges, avoiding broad host cgroup filesystem mounts, and limiting capabilities that permit cgroup manipulation.
• Monitor kernel logs for pressure_write, cgroup_file_release, KASAN use-after-free, NULL dereference, general protection fault, kernel oops, or panic events involving cgroup PSI paths.
• Treat unexplained host crashes on container or multi-user systems as potentially security-relevant until kernel logs and workload activity are reviewed.