CVE-2026-64359 json
nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers
published 2026-07-25 3 mo ago modified 2026-09-04 2 mo ago also EUVD-2026-48903
- cvss
- 5.5
- version 3.1, NVD
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.1%
- EPSS 0.1% chance of exploitation in 30 days, percentile 2%
- public exploits
- 0
- none known
Summary
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().
Patch / fix
- Linux Linux 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.96, 6.18.39, 7.1.4, 7.2
- linux Debian 12 6.1.180-1
- linux Debian 13 6.12.96-1
- linux Debian 14 7.1.4-1
- linux-6.12 Debian 12 6.12.100-1~deb12u1
debian advisories DEBIAN-CVE-2026-64359
- linux Ubuntu 22.04 LTS 5.15.0-198.208
- linux Ubuntu 24.04 LTS 6.8.0-147.147
- linux Ubuntu 26.04 LTS 7.0.0-31.31
- linux-aws Ubuntu 22.04 LTS 5.15.0-1117.124
- linux-aws Ubuntu 24.04 LTS 6.8.0-1067.70
- linux-aws Ubuntu 26.04 LTS 7.0.0-1012.12
- linux-gcp Ubuntu 22.04 LTS 5.15.0-1118.128
- linux-gcp Ubuntu 24.04 LTS 6.8.0-1071.79
ubuntu advisories UBUNTU-CVE-2026-64359
Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
- kernel-source openSUSE Tumbleweed 7.1.7-1.1
opensuse advisories openSUSE-SU-2026:11476-1
- git.kernel.org/stable/c/3ed388ec3b8922383d1e2d4432d7bd4cbbf8364e commit
- git.kernel.org/stable/c/876c98e0fc65f071680c03c2e2ee3ef7ff9ca078 commit
- git.kernel.org/stable/c/39607452b1400c7bf748f15122df4d058b768c5b commit
- git.kernel.org/stable/c/286f77d002a337735c0846d7480a82d9cda2aa31 commit
- git.kernel.org/stable/c/0789f0a6710713254a08f3a7d2ecbb6d1cbcf0aa commit
- git.kernel.org/stable/c/223463c488b0554212a94de971ea538eb2805fc7 commit
- git.kernel.org/stable/c/d26aef771b4f6923da9f89d6d5b70d8def5853de commit
- git.kernel.org/stable/c/0e7a690fe435f8d5ea3feb7c1d8d73ba7e8b8aa9 commit
Vendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2026-64359 updated
kernel: nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernelnot affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.12% chance of exploitation in the next 30 days, higher than 2% of all scored CVEs (FIRST EPSS, 2026-11-08).
CVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| NVD | 3.1 | 5.5 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H |
Affected products
- Linux Linux
Classification
- Technology feeds
References
-
git.kernel.org
/stable/c/3ed388ec3b8922383d1e2d4432d7bd4cbbf8364e
patch
-
git.kernel.org
/stable/c/876c98e0fc65f071680c03c2e2ee3ef7ff9ca078
patch
-
git.kernel.org
/stable/c/39607452b1400c7bf748f15122df4d058b768c5b
patch
-
git.kernel.org
/stable/c/286f77d002a337735c0846d7480a82d9cda2aa31
patch
-
git.kernel.org
/stable/c/0789f0a6710713254a08f3a7d2ecbb6d1cbcf0aa
patch
-
git.kernel.org
/stable/c/223463c488b0554212a94de971ea538eb2805fc7
patch
-
git.kernel.org
/stable/c/d26aef771b4f6923da9f89d6d5b70d8def5853de
patch
-
git.kernel.org
/stable/c/0e7a690fe435f8d5ea3feb7c1d8d73ba7e8b8aa9
patch
Sources
- CVE List CVE-2026-64359
- NVD CVE-2026-64359
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.