ghsa-8wrh-ch6p-2682
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
hugetlbfs: fix null-ptr-deref in hugetlbfs_parse_param()
Syzkaller reports a null-ptr-deref bug as follows:
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:hugetlbfs_parse_param+0x1dd/0x8e0 fs/hugetlbfs/inode.c:1380 [...] Call Trace: vfs_parse_fs_param fs/fs_context.c:148 [inline] vfs_parse_fs_param+0x1f9/0x3c0 fs/fs_context.c:129 vfs_parse_fs_string+0xdb/0x170 fs/fs_context.c:191 generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231 do_new_mount fs/namespace.c:3036 [inline] path_mount+0x12de/0x1e20 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] ======================================================
According to commit "vfs: parse: deal with zero length string value", kernel will set the param->string to null pointer in vfs_parse_fs_string() if fs string has zero length.
Yet the problem is that, hugetlbfs_parse_param() will dereference the param->string, without checking whether it is a null pointer. To be more specific, if hugetlbfs_parse_param() parses an illegal mount parameter, such as "size=,", kernel will constructs struct fs_parameter with null pointer in vfs_parse_fs_string(), then passes this struct fs_parameter to hugetlbfs_parse_param(), which triggers the above null-ptr-deref bug.
This patch solves it by adding sanity check on param->string in hugetlbfs_parse_param().
{
"affected": [],
"aliases": [
"CVE-2022-50334"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-15T15:15:45Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nhugetlbfs: fix null-ptr-deref in hugetlbfs_parse_param()\n\nSyzkaller reports a null-ptr-deref bug as follows:\n======================================================\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nRIP: 0010:hugetlbfs_parse_param+0x1dd/0x8e0 fs/hugetlbfs/inode.c:1380\n[...]\nCall Trace:\n \u003cTASK\u003e\n vfs_parse_fs_param fs/fs_context.c:148 [inline]\n vfs_parse_fs_param+0x1f9/0x3c0 fs/fs_context.c:129\n vfs_parse_fs_string+0xdb/0x170 fs/fs_context.c:191\n generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231\n do_new_mount fs/namespace.c:3036 [inline]\n path_mount+0x12de/0x1e20 fs/namespace.c:3370\n do_mount fs/namespace.c:3383 [inline]\n __do_sys_mount fs/namespace.c:3591 [inline]\n __se_sys_mount fs/namespace.c:3568 [inline]\n __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n [...]\n \u003c/TASK\u003e\n======================================================\n\nAccording to commit \"vfs: parse: deal with zero length string value\",\nkernel will set the param-\u003estring to null pointer in vfs_parse_fs_string()\nif fs string has zero length.\n\nYet the problem is that, hugetlbfs_parse_param() will dereference the\nparam-\u003estring, without checking whether it is a null pointer. To be more\nspecific, if hugetlbfs_parse_param() parses an illegal mount parameter,\nsuch as \"size=,\", kernel will constructs struct fs_parameter with null\npointer in vfs_parse_fs_string(), then passes this struct fs_parameter to\nhugetlbfs_parse_param(), which triggers the above null-ptr-deref bug.\n\nThis patch solves it by adding sanity check on param-\u003estring\nin hugetlbfs_parse_param().",
"id": "GHSA-8wrh-ch6p-2682",
"modified": "2025-09-15T15:31:28Z",
"published": "2025-09-15T15:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50334"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/26215b7ee923b9251f7bb12c4e5f09dc465d35f2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/965e8f8ae0f642b5528f5a82b7bcaf15a659d5bd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a8862820cbf1f18dca4f3b4c289d88561b3a384"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dcd28191be9bbf307ba51a5b485773a55b0037c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f2207145693ae5697a7b59e2add4b92f9e5b0e3c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fa71639873518e3587632ae58e25e4a96b57fa90"
}
],
"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.