CVE-2026-52991

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 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---