Description
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().
Published: 2026-07-25
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel’s nilfs2 file system allows an attacker to invoke the CLEAN_SEGMENTS ioctl with segment numbers that are not validated before the cleaning routine runs. This oversight causes the kernel to acquire the ns_segctor_sem lock, perform repeated printk calls for each invalid entry, and hold the lock long enough for the hung_task watchdog to trigger. The result is that other filesystem operations such as chmod() are blocked for extended periods, potentially causing the system to become unresponsive. The vulnerability is a classic case of improper input validation leading to a local denial-of-service condition when the ioctl is used incorrectly.

Affected Systems

Any Linux kernel version that affected, regardless of vendor. The issue resides in the nilfs2 file system support in the kernel and therefore applies to all users of the nilfs2 driver prior to the patch that validates the segment numbers. Vendors are advised to upgrade to the latest kernel release that incorporates the fix found in commit 0789f0a671.

Risk and Exploitability

The EPSS score is less than 1%, indicating a very low probability of exploitation. The vulnerability is not listed in the CISA KEV catalog. An attacker would need local file system access to a mounted nilfs2 device and the ability to perform the ioctl. The attack vector is local; remote exploitation requires the attacker to gain local access to the filesystem first. Given the low exploitation likelihood and limited impact scope to the system's performance, the overall risk is moderate, but any denial-of-service scenario can be disruptive to production systems.

Generated by OpenCVE AI on August 4, 2026 at 14:37 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to the latest version that includes the nilfs2 clean-segments validation patch (commit 0789f0a671 or later).
  • If upgrading immediately is not possible, restrict the use of NILFS_IOCTL_CLEAN_SEGMENTS to privileged users only by adjusting device permissions or using access control mechanisms.
  • In environments where the patched kernel cannot be installed, avoid invoking the CLEAN_SEGMENTS ioctl with user-supplied segment numbers, or implement pre-validation on the user side to ensure all segment identifiers are within valid bounds.

Generated by OpenCVE AI on August 4, 2026 at 14:37 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4717-1 linux security update
Debian DLA Debian DLA DLA-4720-1 linux security update
Debian DLA Debian DLA DLA-4723-1 linux-6.1 security update
Debian DLA Debian DLA DLA-4724-1 linux-6.12 new package
History

Mon, 03 Aug 2026 19:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-20
CWE-400

Wed, 29 Jul 2026 12:15:00 +0000


Sun, 26 Jul 2026 02:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-20
CWE-400

Sat, 25 Jul 2026 09:30:00 +0000

Type Values Removed Values Added
Description 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().
Title nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-07-25T08:50:15.947Z

Reserved: 2026-07-19T15:36:31.782Z

Link: CVE-2026-64359

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-07-25T10:17:18.377

Modified: 2026-08-11T15:01:50.637

Link: CVE-2026-64359

cve-icon Redhat

Severity :

Publid Date: 2026-07-25T00:00:00Z

Links: CVE-2026-64359 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-04T14:45:03Z

Weaknesses
  • CWE-413

    Improper Resource Locking