GHSA-7CJQ-W44J-QX9W
Vulnerability from github – Published: 2026-07-25 12:31 – Updated: 2026-07-25 12:31In the Linux kernel, the following vulnerability has been resolved:
nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers
Syzbot reported a hung task in nilfs_transaction_begin() where multiple tasks performing chmod() on a nilfs2 mount blocked for over 143 seconds waiting to acquire ns_segctor_sem for read:
INFO: task syz.0.17:5918 blocked for more than 143 seconds. Call Trace: schedule+0x164/0x360 rwsem_down_read_slowpath+0x6d9/0x940 down_read+0x99/0x2e0 nilfs_transaction_begin+0x364/0x710 fs/nilfs2/segment.c:221 nilfs_setattr+0x124/0x2c0 fs/nilfs2/inode.c:921 notify_change+0xc1a/0xf40 chmod_common+0x273/0x4a0 do_fchmodat+0x12d/0x230
The writer holding ns_segctor_sem was a concurrent NILFS_IOCTL_CLEAN_SEGMENTS caller, stuck inside printk while emitting per-element warnings from nilfs_sufile_updatev():
__nilfs_msg+0x373/0x450 fs/nilfs2/super.c:78 nilfs_sufile_updatev+0x21c/0x6d0 fs/nilfs2/sufile.c:186 nilfs_sufile_freev fs/nilfs2/sufile.h:93 [inline] nilfs_free_segments fs/nilfs2/segment.c:1140 [inline] nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1261 [inline] nilfs_segctor_do_construct+0x1f55/0x76c0 nilfs_clean_segments+0x3bd/0xa50 nilfs_ioctl_clean_segments fs/nilfs2/ioctl.c:922 [inline] nilfs_ioctl+0x261f/0x2780
The root cause is that user-supplied segment numbers are not validated before nilfs_clean_segments() begins doing work; the range check on each segnum is performed deep inside the call chain by nilfs_sufile_updatev(), which emits a nilfs_warn() per invalid entry while still holding the segctor lock and the sufile mi_sem. Under load (repeated invocations across multiple mounts saturating the global printk path), the cumulative printk latency keeps ns_segctor_sem held long enough to trip the hung_task watchdog, blocking concurrent operations such as chmod() that need ns_segctor_sem for read.
Fix by validating the contents of kbufs[4] in nilfs_clean_segments() immediately after acquiring ns_segctor_sem via nilfs_transaction_lock(). Holding ns_segctor_sem serializes the check against nilfs_ioctl_resize(), which can modify ns_nsegments, so the validation uses a consistent value. Out-of-range segment numbers are rejected with -EINVAL before any segment-cleaning work begins, so the bad entries never reach the per-element diagnostic path inside nilfs_sufile_updatev().
{
"affected": [],
"aliases": [
"CVE-2026-64359"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-25T10:17:18Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers\n\nSyzbot reported a hung task in nilfs_transaction_begin() where multiple\ntasks performing chmod() on a nilfs2 mount blocked for over 143 seconds\nwaiting to acquire ns_segctor_sem for read:\n\n INFO: task syz.0.17:5918 blocked for more than 143 seconds.\n Call Trace:\n schedule+0x164/0x360\n rwsem_down_read_slowpath+0x6d9/0x940\n down_read+0x99/0x2e0\n nilfs_transaction_begin+0x364/0x710 fs/nilfs2/segment.c:221\n nilfs_setattr+0x124/0x2c0 fs/nilfs2/inode.c:921\n notify_change+0xc1a/0xf40\n chmod_common+0x273/0x4a0\n do_fchmodat+0x12d/0x230\n\nThe writer holding ns_segctor_sem was a concurrent\nNILFS_IOCTL_CLEAN_SEGMENTS caller, stuck inside printk while emitting\nper-element warnings from nilfs_sufile_updatev():\n\n __nilfs_msg+0x373/0x450 fs/nilfs2/super.c:78\n nilfs_sufile_updatev+0x21c/0x6d0 fs/nilfs2/sufile.c:186\n nilfs_sufile_freev fs/nilfs2/sufile.h:93 [inline]\n nilfs_free_segments fs/nilfs2/segment.c:1140 [inline]\n nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1261 [inline]\n nilfs_segctor_do_construct+0x1f55/0x76c0\n nilfs_clean_segments+0x3bd/0xa50\n nilfs_ioctl_clean_segments fs/nilfs2/ioctl.c:922 [inline]\n nilfs_ioctl+0x261f/0x2780\n\nThe root cause is that user-supplied segment numbers are not validated\nbefore nilfs_clean_segments() begins doing work; the range check on\neach segnum is performed deep inside the call chain by\nnilfs_sufile_updatev(), which emits a nilfs_warn() per invalid entry\nwhile still holding the segctor lock and the sufile mi_sem. Under load\n(repeated invocations across multiple mounts saturating the global\nprintk path), the cumulative printk latency keeps ns_segctor_sem held\nlong enough to trip the hung_task watchdog, blocking concurrent\noperations such as chmod() that need ns_segctor_sem for read.\n\nFix by validating the contents of kbufs[4] in nilfs_clean_segments()\nimmediately after acquiring ns_segctor_sem via nilfs_transaction_lock().\nHolding ns_segctor_sem serializes the check against\nnilfs_ioctl_resize(), which can modify ns_nsegments, so the validation\nuses a consistent value. Out-of-range segment numbers are rejected\nwith -EINVAL before any segment-cleaning work begins, so the bad\nentries never reach the per-element diagnostic path inside\nnilfs_sufile_updatev().",
"id": "GHSA-7cjq-w44j-qx9w",
"modified": "2026-07-25T12:31:32Z",
"published": "2026-07-25T12:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64359"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0789f0a6710713254a08f3a7d2ecbb6d1cbcf0aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0e7a690fe435f8d5ea3feb7c1d8d73ba7e8b8aa9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/223463c488b0554212a94de971ea538eb2805fc7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/286f77d002a337735c0846d7480a82d9cda2aa31"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/39607452b1400c7bf748f15122df4d058b768c5b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ed388ec3b8922383d1e2d4432d7bd4cbbf8364e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/876c98e0fc65f071680c03c2e2ee3ef7ff9ca078"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d26aef771b4f6923da9f89d6d5b70d8def5853de"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.