CVE-2026-64359

What it actually does

This flaw is a local denial-of-service condition in the Linux kernel NILFS2 filesystem. The NILFS2 CLEAN_SEGMENTS ioctl accepted user-supplied segment numbers without validating that they were within the valid segment range before beginning segment-cleaning work. Invalid segment numbers were only detected deeper in the call chain while NILFS2 segment-constructor and sufile locks were held. Each invalid entry could trigger kernel warning output through printk while locks remained held, causing long lock hold times and blocking other filesystem operations such as chmod that need the same semaphore. Under repeated or concurrent triggering, this can produce hung tasks, severe filesystem stalls, and kernel watchdog warnings on systems using NILFS2.

Why it matters to the business

Systems that use NILFS2 can experience local service disruption, stalled file operations, degraded host performance, and possible operational outages if an untrusted or compromised local user can trigger the vulnerable ioctl path. The issue is not known to be remotely exploitable, is not listed in CISA KEV, has no known ransomware association, and currently has very low EPSS, but it affects kernel stability and should be prioritized on hosts that mount NILFS2 filesystems or permit users, containers, or workloads to access NILFS2 mounts.

How an attack unfolds

An attacker first obtains local code execution or an account on a Linux system where NILFS2 is available and a NILFS2 filesystem can be accessed. The attacker then opens a file descriptor associated with the NILFS2 mount and repeatedly invokes the NILFS2 CLEAN_SEGMENTS ioctl with segment-number arrays containing values outside the valid range. In vulnerable kernels, NILFS2 accepts the request far enough to acquire the segment-constructor lock and proceed into segment-cleaning logic. The invalid values are later rejected one by one in a lower-level sufile update routine, producing repeated kernel warning messages while locks are still held. With enough invalid entries, repeated invocations, or concurrent activity across mounts, kernel printk latency and lock contention can keep ns_segctor_sem held for long periods. Legitimate filesystem operations that need the same lock then block, and the kernel may report hung tasks, resulting in denial of service for processes using the affected filesystem.

How to fix it

Upgrade to a Linux kernel version that includes the NILFS2 fix rejecting out-of-range CLEAN_SEGMENTS segment numbers in nilfs_clean_segments() before segment-cleaning work begins. If consuming kernels from a Linux distribution or appliance vendor, apply the vendor security update that backports this NILFS2 patch. No exact fixed package versions were provided in the input, so track the relevant vendor advisory for kernel package names and fixed builds. As interim mitigation, avoid mounting NILFS2 on multi-user or untrusted systems, restrict local shell/container access to systems with NILFS2 mounts, disable or avoid loading NILFS2 where it is not required, and use mount, namespace, and capability controls to prevent untrusted users from creating or accessing NILFS2 filesystems.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel build includes the NILFS2 patch that validates kbufs[4] segment numbers in nilfs_clean_segments() and returns -EINVAL for out-of-range values before invoking deeper segment-cleaning paths. Check the running kernel version and distribution changelog for the CVE or for NILFS2 CLEAN_SEGMENTS validation wording. Validate exposure by checking whether NILFS2 is enabled or loaded, whether any NILFS2 filesystems are mounted, and whether untrusted local users or workloads can access those mounts. After patching, a controlled negative test in a non-production environment using invalid segment numbers should fail quickly with EINVAL and should not generate repeated NILFS warnings, hung-task reports, or stalls in concurrent filesystem operations.

Typical attack path

1. Gain local execution on a Linux host where NILFS2 support is present.
2. Identify or create access to a mounted NILFS2 filesystem, subject to local privilege and mount restrictions.
3. Open a file or mount-related file descriptor associated with the NILFS2 filesystem.
4. Submit NILFS_IOCTL_CLEAN_SEGMENTS requests containing out-of-range segment numbers.
5. Repeat the requests or run them concurrently to amplify printk output and lock hold time.
6. Cause legitimate NILFS2 operations, such as chmod or other metadata updates, to block on ns_segctor_sem.
7. Induce filesystem stalls and kernel hung-task warnings, resulting in local denial of service.

How to detect it

To determine whether this was already exploited, review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, and centralized log collectors for hung-task watchdog events and NILFS2 warnings occurring in bursts. Focus on time windows where normal file operations on NILFS2 mounts stalled or processes were blocked for more than the hung-task threshold. Look for stack traces containing nilfs_ioctl_clean_segments, nilfs_clean_segments, nilfs_sufile_updatev, nilfs_segctor_do_construct, nilfs_transaction_begin, ns_segctor_sem, or chmod-related paths blocked on NILFS2. Audit logs, process accounting, shell history, EDR telemetry, or syscall tracing may show unusual local programs repeatedly issuing ioctls against NILFS2 mount points shortly before the kernel log events. Because exploitation primarily produces availability symptoms rather than persistent artifacts, absence of files or malware indicators does not rule it out; correlate kernel warnings with local process execution and user activity at the same timestamps.

• blocked for more than 143 seconds
• INFO: task
• nilfs_transaction_begin
• nilfs_setattr
• nilfs_ioctl_clean_segments
• nilfs_clean_segments
• nilfs_sufile_updatev
• nilfs_segctor_do_construct
• nilfs_segctor_collect_blocks
• NILFS_IOCTL_CLEAN_SEGMENTS
• ns_segctor_sem
• rwsem_down_read_slowpath
• chmod_common
• do_fchmodat
• nilfs2:
• NILFS

What your security team should do

• Inventory Linux hosts for loaded NILFS2 support and active NILFS2 mounts; prioritize hosts where untrusted users, containers, CI jobs, or shared workloads have local access.
• Apply kernel updates from the relevant OS or appliance vendor as soon as available, especially on systems that actively use NILFS2.
• Where patching is delayed, remove or disable NILFS2 usage where not operationally required and restrict access to NILFS2 mounts.
• Review authentication, shell access, container privileges, and mount capabilities to reduce the chance that an untrusted local workload can reach filesystem ioctl interfaces.
• Monitor kernel logs for NILFS2 warning storms, hung-task watchdog messages, and stack traces involving nilfs_ioctl_clean_segments, nilfs_sufile_updatev, or nilfs_transaction_begin.
• Treat unexplained NILFS2-related hung tasks as potential local abuse and preserve kernel logs, audit records, process accounting, and command history for investigation.