CVE-2026-52991: sched/psi: fix race between file release and pressure write

In the Linux kernel, the following vulnerability has been resolved:

sched/psi: fix race between file release and pressure write

A potential race condition exists between pressure write and cgroup file release regarding the priv member of struct kernfsopenfile, which triggers the uaf reported in [1].

Consider the following scenario involving execution on two separate CPUs:

CPU0 CPU1 ==== ==== vfsrmdir() kernfsioprmdir() cgrouprmdir() cgroupknlocklive() cgroupdestroylocked() cgroupaddrmfiles() cgrouprmfile() kernfsremovebyname() kernfsremovebynamens() vfswrite() kernfsremove() newsyncwrite() kernfsdrain() kernfsfopwriteiter() kernfsdrainopenfiles() cgroupfilewrite() kernfsreleasefile() pressurewrite() cgroupfilerelease() ctx = of->priv; kfree(ctx); of->priv = NULL; cgroupknunlock() cgroupknlocklive() cgroupget(cgrp) cgroupknunlock() if (ctx->psi.trigger) // here, trigger uaf for ctx, that is of->priv

The cgrouprmdir() is protected by the cgroupmutex, it also safeguards the memory deallocation of of->priv performed within cgroupfilerelease(). However, the operations involving of->priv executed within pressurewrite() are not entirely covered by the protection of cgroupmutex. Consequently, if the code in pressurewrite(), specifically the section handling the ctx variable executes after cgroupfilerelease() has completed, a uaf vulnerability involving of->priv is triggered.

Therefore, the issue can be resolved by extending the scope of the cgroupmutex lock within pressurewrite() to encompass all code paths involving of->priv, thereby properly synchronizing the race condition occurring between cgroupfilerelease() and pressurewrite().

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 openfile 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 cgroupknlocklive() but before acquiring cgroupmutex, there exists a different class of race condition:

CPU0: write memory.pressure CPU1: write cgroup.pressure=0 =========================== =============================

kernfsfopwriteiter() kernfsgetactiveof(of) pressurewrite() cgroupknlocklive(memory.pressure) cgrouptryget(cgrp) kernfsbreakactiveprotection(kn) ... blocks on cgroupmutex

cgrouppressurewrite() cgroupknlocklive(cgroup.pressure) cgroupfileshow(memory.pressure, false) kernfsshow(false) kernfsdrainopenfiles() cgroupfilerelease(of) kfree(ctx) of->priv = NULL cgroupknunlock()

... acquires cgroupmutex 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 cgroupmutex has been expanded, the original explicit cgroupget/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 pressurewrite+0xa4/0x210 kernel/cgroup/cgroup.c:4011 Call Trace: pressurewrite+0xa4/0x210 kernel/cgroup/cgroup.c:4011 cgroupfilewrite+0x36f/0x790 kernel/cgroup/cgroup.c:43 ---truncated---