Look up another CVE · open CVE-2026-52991 in the interactive tracker
CVE-2026-52991
sched/psi: fix race between file release and pressure write
Published 2026-06-24 (4 months ago) by the Linux kernel CNA. Subsystem kernel/cgroup. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-52991 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | vulnerable | 6.12.113-1 | No fix published anywhere yet, neither in Debian nor upstream for the series trixie tracks. Watch the Debian tracker page for this CVE. Advisories for trixie have historically landed a median of 11 days after publication. |
| Debian 14forky | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.0.10-1 | Update the kernel and reboot. Fixed in 7.0.10-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
A potential race condition exists between pressure write and cgroup file release regarding the priv member of struct kernfs_open_file, which triggers the uaf reported in [1]. Consider the following scenario involving execution on two separate CPUs: CPU0 CPU1 ==== ==== vfs_rmdir() kernfs_iop_rmdir() cgroup_rmdir() cgroup_kn_lock_live() cgroup_destroy_locked() cgroup_addrm_files() cgroup_rm_file() kernfs_remove_by_name() kernfs_remove_by_name_ns() vfs_write() __kernfs_remove() new_sync_write() kernfs_drain() kernfs_fop_write_iter() kernfs_drain_open_files() cgroup_file_write() kernfs_release_file() pressure_write() cgroup_file_release() ctx = of->priv; kfree(ctx); of->priv = NULL; cgroup_kn_unlock() cgroup_kn_lock_live() cgroup_get(cgrp) cgroup_kn_unlock() if (ctx->psi.trigger) // here, trigger uaf for ctx, that is of->priv The cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards the memory deallocation of of->priv performed within cgroup_file_release(). However, the operations involving of->priv executed within pressure_write() are not entirely covered by the protection of cgroup_mutex. Consequently, if the code in pressure_write(), specifically the section handling the ctx variable executes after cgroup_file_release() has completed, a uaf vulnerability involving of->priv is triggered. Therefore, the issue can be resolved by extending the scope of the cgroup_mutex lock within pressure_write() to encompass all code paths involving of->priv, thereby properly synchronizing the race condition occurring between cgroup_file_release() and pressure_write(). And, if an live kn lock can be successfully acquired while executing the pressure write operation, it indicates that the cgroup deletion process has not yet reached its final stage; consequently, the priv pointer within open_file cannot be NULL. Therefore, the operation to retrieve the ctx value must be moved to a point *after* the live kn lock has been successfully acquired. In another situation, specifically after entering cgroup_kn_lock_live() but before acquiring cgroup_mutex, there exists a different class of race condition: CPU0: write memory.pressure CPU1: write cgroup.pressure=0 =========================== ============================= kernfs_fop_write_iter() kernfs_get_active_of(of) pressure_write() cgroup_kn_lock_live(memory.pressure) cgroup_tryget(cgrp) kernfs_break_active_protection(kn) ... blocks on cgroup_mutex cgroup_pressure_write() cgroup_kn_lock_live(cgroup.pressure) cgroup_file_show(memory.pressure, false) kernfs_show(false) kernfs_drain_open_files() cgroup_file_release(of) kfree(ctx) of->priv = NULL cgroup_kn_unlock() ... acquires cgroup_mutex ctx = of->priv; // may now be NULL if (ctx->psi.trigger) // NULL dereference Consequently, there is a possibility that of->priv is NULL, the pressure write needs to check for this. Now that the scope of the cgroup_mutex has been expanded, the original explicit cgroup_get/put operations are no longer necessary, this is because acquiring/releasing the live kn lock inherently executes a cgroup get/put operation. [1] BUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 Call Trace: pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43 ---truncated---
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
kernel/cgroup/cgroup.c
- What this is
- CONTROL GROUP (CGROUP)MAINTAINERS section matched on kernel/cgroup/ · cgroups@vger.kernel.org · Maintained
Check it on the machine
grep -w CONFIG_CGROUPS /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_CGROUPS
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-06-24 (4 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.11%, higher than 1.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- kernel/cgroup
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.2 | 6.18.33 | 03dc070fa0fc |
| 5.2 | 7.0.10 | d4352c0709bf |
| 5.2 | 7.1 | a5b98009f16d |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerable path is reached through local syscalls writing to cgroup v2 PSI control files such as cpu.pressure, memory.pressure, io.pressure, or irq.pressure. There is no network or physical packet-processing path involved.
- AC:LAttack complexity, low
- The attacker can control both sides of the race by concurrently writing a pressure trigger and removing the cgroup or disabling cgroup.pressure to drain open files. No unusual victim state or externally uncontrolled timing condition is required beyond a repeatable local race.
- PR:LPrivileges required, low
- The pressure files are local cgroupfs files; root can always reach them, and unprivileged users can reach equivalent files in delegated cgroup sub-hierarchies they can create and manage. This is therefore low local privilege rather than init-namespace administrator-only.
- UI:NUser interaction, none
- Exploitation only requires attacker-controlled syscalls against cgroupfs file descriptors. No victim user action is needed.
- S:UScope, unchanged
- The vulnerability corrupts kernel memory from a kernel cgroup/PSI file operation and impacts the same kernel security authority. It is not a VM escape, IOMMU bypass, or cross-authority boundary violation.
- C:HConfidentiality impact, high
- This is a slab use-after-free of struct cgroup_file_ctx, and the stale object can be raced with attacker-influenced heap reuse. Following kernel UAF scoring guidance, this can plausibly support kernel memory disclosure primitives.
- I:HIntegrity impact, high
- The pre-fix path can read and later store through the freed ctx->psi.trigger field after the object has been freed, giving a plausible write/corruption primitive with heap grooming. Following kernel UAF scoring guidance, integrity impact is high.
- A:HAvailability impact, high
- The reported bug is a KASAN slab-use-after-free in pressure_write and can crash or oops the kernel. Repeated local triggering can therefore cause high availability impact.