ghsa-7px2-rh6v-wcpc
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
configfs: fix possible memory leak in configfs_create_dir()
kmemleak reported memory leaks in configfs_create_dir():
unreferenced object 0xffff888009f6af00 (size 192): comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163) configfs_register_subsystem (fs/configfs/dir.c:1857) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ...
unreferenced object 0xffff888003ba7180 (size 96): comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s) backtrace: kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273) configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194) configfs_make_dirent (fs/configfs/dir.c:248) configfs_create_dir (fs/configfs/dir.c:296) configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852) configfs_register_subsystem (fs/configfs/dir.c:1881) basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic do_one_initcall (init/main.c:1296) do_init_module (kernel/module/main.c:2455) ...
This is because the refcount is not correct in configfs_make_dirent(). For normal stage, the refcount is changing as:
configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() configfs_new_dirent() # set s_count = 1 dentry->d_fsdata = configfs_get(sd); # s_count = 2 ... configfs_unregister_subsystem() configfs_remove_dir() remove_dir() configfs_remove_dirent() # s_count = 1 dput() ... dentry_unlink_inode() configfs_d_iput() # s_count = 0, release
However, if we failed in configfs_create():
configfs_register_subsystem() configfs_create_dir() configfs_make_dirent() # s_count = 2 ... configfs_create() # fail ->out_remove: configfs_remove_dirent(dentry) configfs_put(sd) # s_count = 1 return PTR_ERR(inode);
There is no inode in the error path, so the configfs_d_iput() is lost and makes sd and fragment memory leaked.
To fix this, when we failed in configfs_create(), manually call configfs_put(sd) to keep the refcount correct.
{
"affected": [],
"aliases": [
"CVE-2022-50751"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-24T13:16:01Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nconfigfs: fix possible memory leak in configfs_create_dir()\n\nkmemleak reported memory leaks in configfs_create_dir():\n\nunreferenced object 0xffff888009f6af00 (size 192):\n comm \"modprobe\", pid 3777, jiffies 4295537735 (age 233.784s)\n backtrace:\n kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)\n new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163)\n configfs_register_subsystem (fs/configfs/dir.c:1857)\n basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic\n do_one_initcall (init/main.c:1296)\n do_init_module (kernel/module/main.c:2455)\n ...\n\nunreferenced object 0xffff888003ba7180 (size 96):\n comm \"modprobe\", pid 3777, jiffies 4295537735 (age 233.784s)\n backtrace:\n kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)\n configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194)\n configfs_make_dirent (fs/configfs/dir.c:248)\n configfs_create_dir (fs/configfs/dir.c:296)\n configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852)\n configfs_register_subsystem (fs/configfs/dir.c:1881)\n basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic\n do_one_initcall (init/main.c:1296)\n do_init_module (kernel/module/main.c:2455)\n ...\n\nThis is because the refcount is not correct in configfs_make_dirent().\nFor normal stage, the refcount is changing as:\n\nconfigfs_register_subsystem()\n configfs_create_dir()\n configfs_make_dirent()\n configfs_new_dirent() # set s_count = 1\n dentry-\u003ed_fsdata = configfs_get(sd); # s_count = 2\n...\nconfigfs_unregister_subsystem()\n configfs_remove_dir()\n remove_dir()\n configfs_remove_dirent() # s_count = 1\n dput() ...\n *dentry_unlink_inode()*\n configfs_d_iput() # s_count = 0, release\n\nHowever, if we failed in configfs_create():\n\nconfigfs_register_subsystem()\n configfs_create_dir()\n configfs_make_dirent() # s_count = 2\n ...\n configfs_create() # fail\n -\u003eout_remove:\n configfs_remove_dirent(dentry)\n configfs_put(sd) # s_count = 1\n return PTR_ERR(inode);\n\nThere is no inode in the error path, so the configfs_d_iput() is lost\nand makes sd and fragment memory leaked.\n\nTo fix this, when we failed in configfs_create(), manually call\nconfigfs_put(sd) to keep the refcount correct.",
"id": "GHSA-7px2-rh6v-wcpc",
"modified": "2025-12-24T15:30:34Z",
"published": "2025-12-24T15:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50751"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/07f82dca112262b169bec0001378126439cab776"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/74ac7c9ee2d486c501e7864c903f5098fc477acd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8bc77754224a2c8581727ffe2e958119b4e27c8f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/90c38f57a821499391526b15cc944c265bd24e48"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c65234b283a65cfbfc94619655e820a5e55199eb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c72eb6e6e49a71f7598740786568fafdd013a227"
}
],
"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.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- 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.