CVE-2026-64359: nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: reject CLEANSEGMENTS ioctl with out-of-range segment numbers
Syzbot reported a hung task in nilfstransactionbegin() where multiple tasks performing chmod() on a nilfs2 mount blocked for over 143 seconds waiting to acquire nssegctorsem for read:
INFO: task syz.0.17:5918 blocked for more than 143 seconds. Call Trace: schedule+0x164/0x360 rwsemdownreadslowpath+0x6d9/0x940 downread+0x99/0x2e0 nilfstransactionbegin+0x364/0x710 fs/nilfs2/segment.c:221 nilfssetattr+0x124/0x2c0 fs/nilfs2/inode.c:921 notifychange+0xc1a/0xf40 chmodcommon+0x273/0x4a0 dofchmodat+0x12d/0x230
The writer holding nssegctorsem was a concurrent NILFSIOCTLCLEANSEGMENTS caller, stuck inside printk while emitting per-element warnings from nilfssufileupdatev():
nilfsmsg+0x373/0x450 fs/nilfs2/super.c:78 nilfssufileupdatev+0x21c/0x6d0 fs/nilfs2/sufile.c:186 nilfssufilefreev fs/nilfs2/sufile.h:93 [inline] nilfsfreesegments fs/nilfs2/segment.c:1140 [inline] nilfssegctorcollectblocks fs/nilfs2/segment.c:1261 [inline] nilfssegctordoconstruct+0x1f55/0x76c0 nilfscleansegments+0x3bd/0xa50 nilfsioctlcleansegments fs/nilfs2/ioctl.c:922 [inline] nilfsioctl+0x261f/0x2780
The root cause is that user-supplied segment numbers are not validated before nilfscleansegments() begins doing work; the range check on each segnum is performed deep inside the call chain by nilfssufileupdatev(), which emits a nilfswarn() per invalid entry while still holding the segctor lock and the sufile misem. Under load (repeated invocations across multiple mounts saturating the global printk path), the cumulative printk latency keeps nssegctorsem held long enough to trip the hungtask watchdog, blocking concurrent operations such as chmod() that need nssegctorsem for read.
Fix by validating the contents of kbufs[4] in nilfscleansegments() immediately after acquiring nssegctorsem via nilfstransactionlock(). Holding nssegctorsem serializes the check against nilfsioctlresize(), which can modify nsnsegments, 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 nilfssufileupdatev().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the fix so nilfs2 rejects CLEAN_SEGMENTS ioctl calls that include out-of-range segment numbers. The validation must occur up-front (before nilfs_clean_segments() does any work), and invalid entries must fail with -EINVAL to avoid printk latency holding ns_segctor_sem long enough to trigger hung_task/watchdog timeouts.
nilfs2 CLEAN_SEGMENTS ioctl segment number validation = reject out-of-range segment numbers with -EINVAL before nilfs_clean_segments begins work
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems with a nilfs2 filesystem mount are exposed to the described denial-of-service condition. The affected path is the NILFS_IOCTL_CLEAN_SEGMENTS ioctl and can block other operations such as chmod() on that mount.
What access does an attacker need?
The CVSS vector indicates local access, low attack complexity, low privileges, and no user interaction. Exploitation requires a local low-privileged caller able to invoke the affected ioctl against a nilfs2 mount.
What is the impact if exploited?
An attacker can cause tasks accessing the nilfs2 mount to hang while waiting for ns_segctor_sem. The reported behavior involved chmod() tasks blocked for more than 143 seconds, resulting in an availability impact rather than confidentiality or integrity impact.
How can exposure be reduced before a fix is applied?
Limit untrusted local users' access to nilfs2 mounts and prevent them from invoking NILFS_IOCTL_CLEAN_SEGMENTS where possible. Monitor for hung tasks involving nilfs_transaction_begin(), ns_segctor_sem, or nilfs_clean_segments.