CVE-2026-52991

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/psi: fix race between file release and pressure write<br /> <br /> A potential race condition exists between pressure write and cgroup file<br /> release regarding the priv member of struct kernfs_open_file, which<br /> triggers the uaf reported in [1].<br /> <br /> Consider the following scenario involving execution on two separate CPUs:<br /> <br /> CPU0 CPU1<br /> ==== ====<br /> vfs_rmdir()<br /> kernfs_iop_rmdir()<br /> cgroup_rmdir()<br /> cgroup_kn_lock_live()<br /> cgroup_destroy_locked()<br /> cgroup_addrm_files()<br /> cgroup_rm_file()<br /> kernfs_remove_by_name()<br /> kernfs_remove_by_name_ns()<br /> vfs_write() __kernfs_remove()<br /> new_sync_write() kernfs_drain()<br /> kernfs_fop_write_iter() kernfs_drain_open_files()<br /> cgroup_file_write() kernfs_release_file()<br /> pressure_write() cgroup_file_release()<br /> ctx = of-&gt;priv;<br /> kfree(ctx);<br /> of-&gt;priv = NULL;<br /> cgroup_kn_unlock()<br /> cgroup_kn_lock_live()<br /> cgroup_get(cgrp)<br /> cgroup_kn_unlock()<br /> if (ctx-&gt;psi.trigger) // here, trigger uaf for ctx, that is of-&gt;priv<br /> <br /> The cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards<br /> the memory deallocation of of-&gt;priv performed within cgroup_file_release().<br /> However, the operations involving of-&gt;priv executed within pressure_write()<br /> are not entirely covered by the protection of cgroup_mutex. Consequently,<br /> if the code in pressure_write(), specifically the section handling the<br /> ctx variable executes after cgroup_file_release() has completed, a uaf<br /> vulnerability involving of-&gt;priv is triggered.<br /> <br /> Therefore, the issue can be resolved by extending the scope of the<br /> cgroup_mutex lock within pressure_write() to encompass all code paths<br /> involving of-&gt;priv, thereby properly synchronizing the race condition<br /> occurring between cgroup_file_release() and pressure_write().<br /> <br /> And, if an live kn lock can be successfully acquired while executing<br /> the pressure write operation, it indicates that the cgroup deletion<br /> process has not yet reached its final stage; consequently, the priv<br /> pointer within open_file cannot be NULL. Therefore, the operation to<br /> retrieve the ctx value must be moved to a point *after* the live kn<br /> lock has been successfully acquired.<br /> <br /> In another situation, specifically after entering cgroup_kn_lock_live()<br /> but before acquiring cgroup_mutex, there exists a different class of<br /> race condition:<br /> <br /> CPU0: write memory.pressure CPU1: write cgroup.pressure=0<br /> =========================== =============================<br /> <br /> kernfs_fop_write_iter()<br /> kernfs_get_active_of(of)<br /> pressure_write()<br /> cgroup_kn_lock_live(memory.pressure)<br /> cgroup_tryget(cgrp)<br /> kernfs_break_active_protection(kn)<br /> ... blocks on cgroup_mutex<br /> <br /> cgroup_pressure_write()<br /> cgroup_kn_lock_live(cgroup.pressure)<br /> cgroup_file_show(memory.pressure, false)<br /> kernfs_show(false)<br /> kernfs_drain_open_files()<br /> cgroup_file_release(of)<br /> kfree(ctx)<br /> of-&gt;priv = NULL<br /> cgroup_kn_unlock()<br /> <br /> ... acquires cgroup_mutex<br /> ctx = of-&gt;priv; // may now be NULL<br /> if (ctx-&gt;psi.trigger) // NULL dereference<br /> <br /> Consequently, there is a possibility that of-&gt;priv is NULL, the pressure<br /> write needs to check for this.<br /> <br /> Now that the scope of the cgroup_mutex has been expanded, the original<br /> explicit cgroup_get/put operations are no longer necessary, this is<br /> because acquiring/releasing the live kn lock inherently executes a<br /> cgroup get/put operation.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011<br /> Call Trace:<br /> pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011<br /> cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43<br /> ---truncated---