ghsa-v6rx-qqxh-7pj6
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
spufs: fix gang directory lifetimes
prior to "[POWERPC] spufs: Fix gang destroy leaks" we used to have a problem with gang lifetimes - creation of a gang returns opened gang directory, which normally gets removed when that gets closed, but if somebody has created a context belonging to that gang and kept it alive until the gang got closed, removal failed and we ended up with a leak.
Unfortunately, it had been fixed the wrong way. Dentry of gang directory was no longer pinned, and rmdir on close was gone. One problem was that failure of open kept calling simple_rmdir() as cleanup, which meant an unbalanced dput(). Another bug was in the success case - gang creation incremented link count on root directory, but that was no longer undone when gang got destroyed.
Fix consists of * reverting the commit in question * adding a counter to gang, protected by ->i_rwsem of gang directory inode. * having it set to 1 at creation time, dropped in both spufs_dir_close() and spufs_gang_close() and bumped in spufs_create_context(), provided that it's not 0. * using simple_recursive_removal() to take the gang directory out when counter reaches zero.
{
"affected": [],
"aliases": [
"CVE-2025-22072"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-16T15:16:01Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nspufs: fix gang directory lifetimes\n\nprior to \"[POWERPC] spufs: Fix gang destroy leaks\" we used to have\na problem with gang lifetimes - creation of a gang returns opened\ngang directory, which normally gets removed when that gets closed,\nbut if somebody has created a context belonging to that gang and\nkept it alive until the gang got closed, removal failed and we\nended up with a leak.\n\nUnfortunately, it had been fixed the wrong way. Dentry of gang\ndirectory was no longer pinned, and rmdir on close was gone.\nOne problem was that failure of open kept calling simple_rmdir()\nas cleanup, which meant an unbalanced dput(). Another bug was\nin the success case - gang creation incremented link count on\nroot directory, but that was no longer undone when gang got\ndestroyed.\n\nFix consists of\n\t* reverting the commit in question\n\t* adding a counter to gang, protected by -\u003ei_rwsem\nof gang directory inode.\n\t* having it set to 1 at creation time, dropped\nin both spufs_dir_close() and spufs_gang_close() and bumped\nin spufs_create_context(), provided that it\u0027s not 0.\n\t* using simple_recursive_removal() to take the gang\ndirectory out when counter reaches zero.",
"id": "GHSA-v6rx-qqxh-7pj6",
"modified": "2025-04-16T15:34:43Z",
"published": "2025-04-16T15:34:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22072"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/029d8c711f5e5fe8cf63e8a4a1a140a06e224e45"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/324f280806aab28ef757aecc18df419676c10ef8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/880e7b3da2e765c1f90c94c0539be039e96c7062"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/903733782f3ae28a2f7fe4dfb47c7fe3e079a528"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c134deabf4784e155d360744d4a6a835b9de4dd4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fc646a6c6d14b5d581f162a7e32999f789e3a3ac"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.