CVE-2026-64359 in Linux
Summary
by MITRE • 07/25/2026
In 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().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/26/2026
The vulnerability in question affects the Linux kernel's nilfs2 file system implementation and stems from inadequate input validation during ioctl operations. This flaw manifests as a potential denial of service condition where concurrent system operations become blocked indefinitely due to improper handling of segment numbers in the CLEAN_SEGMENTS ioctl command. The root cause lies in the lack of early validation for user-supplied segment identifiers, which allows invalid values to propagate through the system call chain before being rejected. When multiple processes attempt to perform chmod operations on a nilfs2 mount simultaneously, they encounter prolonged blocking periods as they wait for access to the ns_segctor_sem semaphore. This semaphore is held by a background process executing the CLEAN_SEGMENTS ioctl that becomes stuck in the printk subsystem while generating diagnostic warnings for out-of-range segment numbers.
The technical execution path reveals a complex interaction between multiple kernel components where the validation logic is deferred until deep within the call stack, specifically inside nilfs_sufile_updatev() function. This delayed validation approach creates a critical race condition where the system holds locks for extended periods while processing potentially malformed input through the printk mechanism. The problematic behavior occurs when the kernel attempts to process segment numbers that exceed the valid range of the file system's segment structure, causing the diagnostic warning generation to consume significant CPU time and lock resources. Under high load conditions with multiple concurrent operations, this creates a cascading effect where the hung_task watchdog triggers due to the prolonged semaphore holding time.
The operational impact of this vulnerability extends beyond simple performance degradation to potentially complete system unresponsiveness during critical file system maintenance operations. The blocking behavior affects common file system operations like chmod and other attribute modifications, which can severely impact system stability and user experience. This issue represents a classic case of improper input validation that allows malformed data to reach critical system resources, creating opportunities for denial of service attacks or system instability under concurrent workloads. The vulnerability directly maps to CWE-129 Input Validation and CWE-691 Uncontrolled Resource Consumption, demonstrating how inadequate parameter checking can lead to resource exhaustion through lock contention.
The mitigation strategy involves implementing immediate validation of segment numbers within the nilfs_clean_segments() function before any significant processing occurs. By performing range checks right after acquiring the ns_segctor_sem through nilfs_transaction_lock(), the system prevents invalid segment numbers from reaching the problematic diagnostic code path that holds locks for extended periods. This approach ensures that out-of-range segment identifiers are rejected with -EINVAL error codes before any segment cleaning work begins, eliminating the need for per-element warning generation that causes the lock contention. The fix leverages the existing locking mechanism to provide consistent validation against potential modifications to ns_nsegments by concurrent resize operations while maintaining system stability and preventing the accumulation of diagnostic print messages that contribute to the overall blocking behavior.
This vulnerability demonstrates the critical importance of early input validation in kernel space operations and highlights how seemingly simple parameter checks can prevent complex race conditions and resource exhaustion scenarios. The solution aligns with ATT&CK technique T1499.004 for Resource Exhaustion by preventing uncontrolled consumption of system resources through lock contention, while also addressing the fundamental security principle of validating all inputs before processing them in privileged contexts. The fix maintains the intended functionality of the CLEAN_SEGMENTS ioctl while eliminating the potential for denial of service conditions that could be exploited under stress conditions or through malicious input manipulation.