Backport of the CVE-2026-52991 fix.

  1/2 (94a4acfec146) clear of->priv on release, turning the UAF into an
      easier-to-detect NULL deref.
  2/2 (a5b98009f16d, the CVE fix) extend cgroup_mutex to cover all
      of->priv accesses, read ctx after taking the kn lock, and NULL-check
      of->priv. It depends on 1/2 as discussed in [0].

[0] https://lore.kernel.org/all/8a06c5c3-8f7a-4252-a3b1-0c0d812e2654@oracle.com/

Chen Ridong (1):
  cgroup/psi: Set of->priv to NULL upon file release

Edward Adam Davis (1):
  sched/psi: fix race between file release and pressure write

 kernel/cgroup/cgroup.c | 25 +++++++++++++++++--------
 1 file changed, 17 insertions(+), 8 deletions(-)

--
2.47.3

On Wed, Jul 15, 2026 at 04:32:43PM +0800, Philo Lu wrote:
> Backport of the CVE-2026-52991 fix.
>
>   1/2 (94a4acfec146) clear of->priv on release, turning the UAF into an
>       easier-to-detect NULL deref.
>   2/2 (a5b98009f16d, the CVE fix) extend cgroup_mutex to cover all
>       of->priv accesses, read ctx after taking the kn lock, and NULL-check
>       of->priv. It depends on 1/2 as discussed in [0].

I'm holding off on this series (and the 6.6.y/6.1.y ones) for now: a5b98009f16d
moves the psi trigger write path under cgroup_mutex, which means the psimon
kthread gets created while holding cgroup_mutex and introduces a deadlock risk.

Tejun has a follow-up fix for that which is in the cgroup tree but hasn't
reached mainline yet. Once it lands, I'll queue your series together with it on
all three branches.

-- 
Thanks,
Sasha

On 7/17/26 9:37 AM, Sasha Levin wrote:

> I'm holding off on this series (and the 6.6.y/6.1.y ones) for now: a5b98009f16d
> moves the psi trigger write path under cgroup_mutex, which means the psimon
> kthread gets created while holding cgroup_mutex and introduces a deadlock risk.
> 

Thanks for the heads-up, Sasha, and sorry I missed the patch you pointed 
out.

BTW, I have an unrelated question. I'd like to backport some stable 
patches to earlier LTS trees (e.g. from 6.18 down to 6.6). For patchsets 
like this one that apply cleanly to multiple versions (6.1, 6.6, and 
6.12), which of the following is preferred?

(1) A single patchset covering all three trees, with subjects like 
"[PATCH 6.1.y/6.6.y/6.12.y] ..."

(2) Three separate patchsets, one per stable tree.

Thanks.
-- 
Philo

> BTW, I have an unrelated question. I'd like to backport some stable
> patches to earlier LTS trees (e.g. from 6.18 down to 6.6). For patchsets
> like this one that apply cleanly to multiple versions (6.1, 6.6, and
> 6.12), which of the following is preferred?
>
> (1) A single patchset covering all three trees, with subjects like
> "[PATCH 6.1.y/6.6.y/6.12.y] ..."
>
> (2) Three separate patchsets, one per stable tree.

A single combined patchset is fine when the same patches apply cleanly
to all the target trees - just list the versions in the subject like
you described. Separate per-tree submissions are only needed when the
backports diverge.

On this series: still holding for now - Tejun's fix for the psimon
creation under cgroup_mutex hasn't landed in mainline yet. Once it
does, I'll queue the series for 6.12, 6.6, and 6.1.

-- 
Thanks,
Sasha