From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2157C3101BF for ; Wed, 24 Jun 2026 16:33:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782318840; cv=none; b=Bo0IO9m+Vdu26MCxLLit4bcZ//gwlcuk2nCB/F/pPe5WWwoO6YFxEWSykq3MDb/y7wgSbsdLNZBUbQhd6Wm2g/CKp5mKlRCxxorPw/fcK/ym/Buizg0U3ta31rT9+5gq7T08EcODxHAWwVgEUIJs8Dpjbyxr77+P9kqMNiDqA3A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782318840; c=relaxed/simple; bh=GGeaheFXQlUST+qBvErB0ydtvFmrGVtR5Eix7wij3fY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=E+nIzNd9yjNwwiG+wp/rpg/n4K0nrkjviSf/KqPq+V9uApqDceZNwYS52860zQoBlXY/gmVUxWff54leC/bVOd1vyH1OzwqTcJeg0A1bMk8pwghpod7FmS2Bh6jK/PsJyC/5qiVpO8XFvL0fIseT4Zh3BXgxIogClbPDe97FUxQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=RRi9waZH; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="RRi9waZH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67E971F000E9; Wed, 24 Jun 2026 16:33:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1782318839; bh=hGx5DnArzk/NmOXt68lHuUtWVvySVovM22tSp22vC6Q=; h=From:To:Cc:Subject:Date:Reply-To; b=RRi9waZHzzG4CJf7SChesm4Vi0lsV6iIHu3uWbzsJ3iuZKVPEC1MdRll5ilUI33j/ 9t5OTjlEFgrvFFGI0qhj9Ri9eSr0PeY4GJsE/1iAfFDgjXfzELB80XseotB+tJFWt3 m8plAbUqOMVRhwcbkXleG6aHs7q8xHZmrPVcQMVQ= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2026-52991: sched/psi: fix race between file release and pressure write Date: Wed, 24 Jun 2026 17:30:15 +0100 Message-ID: <2026062444-CVE-2026-52991-18fe@gregkh> X-Mailer: git-send-email 2.54.0 Reply-To: , Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=6415; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=gmSwV4KmdUqlzA8z1jaKZYxHpyIR24vl1NlmGPdrCeI=; b=owGbwMvMwCRo6H6F97bub03G02pJDFk2rD9m/Z2kbO2YP8tc7bH81/DUD1rBlhva1Ng+b0sJK vhYxxXeEcvCIMjEICumyPJlG8/R/RWHFL0MbU/DzGFlAhnCwMUpABM50MowT0E6QN/0lER7oiPf 8ap/O7tLrss7M8wPWilct4R7zpIXxreT+N99y+KTrr0MAA== X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman Description =========== 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:4311 kernfs_fop_write_iter+0x3b0/0x540 fs/kernfs/file.c:352 Allocated by task 9352: cgroup_file_open+0x90/0x3a0 kernel/cgroup/cgroup.c:4256 kernfs_fop_open+0x9eb/0xcb0 fs/kernfs/file.c:724 do_dentry_open+0x83d/0x13e0 fs/open.c:949 Freed by task 9353: cgroup_file_release+0xd6/0x100 kernel/cgroup/cgroup.c:4283 kernfs_release_file fs/kernfs/file.c:764 [inline] kernfs_drain_open_files+0x392/0x720 fs/kernfs/file.c:834 kernfs_drain+0x470/0x600 fs/kernfs/dir.c:525 The Linux kernel CVE team has assigned CVE-2026-52991 to this issue. Affected and fixed versions =========================== Issue introduced in 5.2 with commit 0e94682b73bfa6c44c98af7a26771c9c08c055d5 and fixed in 6.18.33 with commit 03dc070fa0fc3cb4068693f468ccd5f8a7e58282 Issue introduced in 5.2 with commit 0e94682b73bfa6c44c98af7a26771c9c08c055d5 and fixed in 7.0.10 with commit d4352c0709bfd38c752fccbde7fd72a82ac78f23 Issue introduced in 5.2 with commit 0e94682b73bfa6c44c98af7a26771c9c08c055d5 and fixed in 7.1 with commit a5b98009f16d8a5fb4a8ff9a193f5735515c38fa Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2026-52991 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: kernel/cgroup/cgroup.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/03dc070fa0fc3cb4068693f468ccd5f8a7e58282 https://git.kernel.org/stable/c/d4352c0709bfd38c752fccbde7fd72a82ac78f23 https://git.kernel.org/stable/c/a5b98009f16d8a5fb4a8ff9a193f5735515c38fa