GHSA-3V2R-C9X3-5FGR
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-08-20 15:33In 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---
{
"affected": [],
"aliases": [
"CVE-2026-52991"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:09Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/psi: fix race between file release and pressure write\n\nA potential race condition exists between pressure write and cgroup file\nrelease regarding the priv member of struct kernfs_open_file, which\ntriggers the uaf reported in [1].\n\nConsider the following scenario involving execution on two separate CPUs:\n\n CPU0\t\t\t\t\tCPU1\n ====\t\t\t\t\t====\n\t\t\t\t\tvfs_rmdir()\n\t\t\t\t\tkernfs_iop_rmdir()\n\t\t\t\t\tcgroup_rmdir()\n\t\t\t\t\tcgroup_kn_lock_live()\n\t\t\t\t\tcgroup_destroy_locked()\n\t\t\t\t\tcgroup_addrm_files()\n\t\t\t\t\tcgroup_rm_file()\n\t\t\t\t\tkernfs_remove_by_name()\n\t\t\t\t\tkernfs_remove_by_name_ns()\n vfs_write()\t\t\t\t__kernfs_remove()\n new_sync_write()\t\t\tkernfs_drain()\n kernfs_fop_write_iter()\t\tkernfs_drain_open_files()\n cgroup_file_write()\t\t\tkernfs_release_file()\n pressure_write()\t\t\tcgroup_file_release()\n ctx = of-\u003epriv;\n\t\t\t\t\tkfree(ctx);\n \t\t\t\t\tof-\u003epriv = NULL;\n\t\t\t\t\tcgroup_kn_unlock()\n cgroup_kn_lock_live()\n cgroup_get(cgrp)\n cgroup_kn_unlock()\n if (ctx-\u003epsi.trigger) // here, trigger uaf for ctx, that is of-\u003epriv\n\nThe cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards\nthe memory deallocation of of-\u003epriv performed within cgroup_file_release().\nHowever, the operations involving of-\u003epriv executed within pressure_write()\nare not entirely covered by the protection of cgroup_mutex. Consequently,\nif the code in pressure_write(), specifically the section handling the\nctx variable executes after cgroup_file_release() has completed, a uaf\nvulnerability involving of-\u003epriv is triggered.\n\nTherefore, the issue can be resolved by extending the scope of the\ncgroup_mutex lock within pressure_write() to encompass all code paths\ninvolving of-\u003epriv, thereby properly synchronizing the race condition\noccurring between cgroup_file_release() and pressure_write().\n\nAnd, if an live kn lock can be successfully acquired while executing\nthe pressure write operation, it indicates that the cgroup deletion\nprocess has not yet reached its final stage; consequently, the priv\npointer within open_file cannot be NULL. Therefore, the operation to\nretrieve the ctx value must be moved to a point *after* the live kn\nlock has been successfully acquired.\n\nIn another situation, specifically after entering cgroup_kn_lock_live()\nbut before acquiring cgroup_mutex, there exists a different class of\nrace condition:\n\nCPU0: write memory.pressure CPU1: write cgroup.pressure=0\n===========================\t\t =============================\n\nkernfs_fop_write_iter()\n kernfs_get_active_of(of)\n pressure_write()\n cgroup_kn_lock_live(memory.pressure)\n cgroup_tryget(cgrp)\n kernfs_break_active_protection(kn)\n ... blocks on cgroup_mutex\n\n \t cgroup_pressure_write()\n \t cgroup_kn_lock_live(cgroup.pressure)\n \t cgroup_file_show(memory.pressure, false)\n \t kernfs_show(false)\n \t kernfs_drain_open_files()\n \t cgroup_file_release(of)\n \t kfree(ctx)\n \t of-\u003epriv = NULL\n \t cgroup_kn_unlock()\n\n ... acquires cgroup_mutex\n ctx = of-\u003epriv; // may now be NULL\n if (ctx-\u003epsi.trigger) // NULL dereference\n\nConsequently, there is a possibility that of-\u003epriv is NULL, the pressure\nwrite needs to check for this.\n\nNow that the scope of the cgroup_mutex has been expanded, the original\nexplicit cgroup_get/put operations are no longer necessary, this is\nbecause acquiring/releasing the live kn lock inherently executes a\ncgroup get/put operation.\n\n[1]\nBUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011\nCall Trace:\n pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011\n cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43\n---truncated---",
"id": "GHSA-3v2r-c9x3-5fgr",
"modified": "2026-08-20T15:33:25Z",
"published": "2026-06-24T18:32:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52991"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:57251"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:57252"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:57253"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:57254"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-52991"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492403"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03dc070fa0fc3cb4068693f468ccd5f8a7e58282"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5b98009f16d8a5fb4a8ff9a193f5735515c38fa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4352c0709bfd38c752fccbde7fd72a82ac78f23"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52991.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.