CVE-2026-89666: Linux Kernel NFSv3 Information Disclosure

CVE-2026-89666 Overview

CVE-2026-89666 is an input validation flaw in the Linux kernel NFS server (nfsd). The server fails to reject out-of-range nseconds values in NFSv3 SETATTR, CREATE, MKDIR, SYMLINK, and MKNOD operations. A client can supply an atime or mtime whose tv_nsec field exceeds NSEC_PER_SEC, which is not a valid timespec64. Nothing in the setattr path clamps the value before it reaches on-disk metadata encoders. The un-normalized value corrupts stored timestamps on ext4 and XFS with bigtime enabled.

Critical Impact
A remote NFSv3 client can corrupt on-disk timestamp metadata on ext4 and XFS filesystems by supplying malformed nanosecond values, causing incorrect year and time values on read-back.

Affected Products

Linux kernel nfsd subsystem (NFSv3 server implementation)
ext4 filesystem timestamp encoding (ext4_encode_extra_time)
XFS filesystem with bigtime timestamp format enabled

Discovery Timeline

2026-09-11 - CVE-2026-89666 published to the National Vulnerability Database
2026-09-11 - Last updated in NVD database

Technical Details for CVE-2026-89666

Vulnerability Analysis

The vulnerability resides in the NFSv3 server request handlers in the Linux kernel. A client can send a SETATTR or object-creation request carrying an atime or mtime whose nseconds field decodes cleanly into a valid uint32 but exceeds NSEC_PER_SEC (1,000,000,000). This value is not a valid timespec64.

The setattr path does not clamp the value. notify_change() invokes timestamp_truncate(), which does not reduce tv_nsec below NSEC_PER_SEC when the filesystem advertises nanosecond granularity (s_time_gran == 1). Only ctime is normalized through inode_set_ctime_to_ts(); the inode atime and mtime setters store the client-supplied value verbatim.

Downstream filesystem encoders then corrupt on-disk state. In ext4, ext4_encode_extra_time() shifts tv_nsec left by EXT4_EPOCH_BITS, overflowing the 32-bit extra field and clobbering the seconds-epoch bits. Stored seconds, and therefore the year, are wrong on read-back. XFS with bigtime enabled mis-stores the timestamp for the same reason.

Root Cause

The root cause is missing input validation [Improper Input Validation] on client-supplied timestamps in the NFSv3 proc handlers. The tv_nsec field is a long, and a malformed wire value can be assigned to a 32-bit long such that it becomes negative or exceeds NSEC_PER_SEC. Neither the server nor the underlying VFS layer enforces timespec64_valid() semantics before the value reaches the filesystem's timestamp encoder.

Attack Vector

An authenticated NFSv3 client sends a crafted SETATTR, CREATE, MKDIR, SYMLINK, or MKNOD request with an atime or mtimenseconds value greater than or equal to NSEC_PER_SEC. The server accepts the request, applies the timestamp to a new or existing inode, and the filesystem encodes corrupted metadata. Subsequent reads of the file return incorrect timestamps, and in ext4 the corruption affects seconds-epoch bits, shifting the stored year.

The fix validates client-supplied atime and mtime in the proc handlers before any object is created and returns NFS3ERR_INVAL for out-of-range values, matching RFC 1813 guidance. SET_TO_SERVER_TIME requests carry no client value and are unaffected. The sattrguard3 ctime is deliberately not validated so an out-of-range guard yields NFS3ERR_NOT_SYNC via the existing guardtime comparison.

Detection Methods for CVE-2026-89666

Indicators of Compromise

Files on NFS-exported ext4 or XFS filesystems showing implausible timestamps, particularly years far in the past or future after client-initiated changes.
NFSv3 SETATTR, CREATE, MKDIR, SYMLINK, or MKNOD requests containing nseconds values greater than or equal to 1000000000 in packet captures.
Filesystem consistency check reports flagging timestamp fields with anomalous seconds-epoch bits on ext4 inodes.

Detection Strategies

Inspect NFSv3 RPC traffic to servers using packet capture tools and filter for setattr and create operations with malformed tv_nsec fields.
Baseline expected timestamp ranges on NFS-exported volumes and alert on outliers introduced through the NFS server.
Correlate kernel version data with NFSv3 export configuration to identify unpatched nfsd instances.

Monitoring Recommendations

Enable audit logging on NFS-exported directories and monitor for file creation and attribute-change events with anomalous timestamp values.
Track kernel package versions across Linux fleet inventory and flag hosts running affected nfsd builds.
Monitor NFSv3 client populations for hosts issuing malformed RPC payloads that may indicate reconnaissance or exploitation attempts.

How to Mitigate CVE-2026-89666

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the git.kernel.org commits and rebuild or update the running kernel on all NFSv3 servers.
Restrict NFSv3 export access to trusted client subnets using /etc/exports host controls and firewall rules until patches are deployed.
Audit ext4 and XFS filesystems exported over NFSv3 for timestamp corruption and restore affected metadata from backups where required.

Patch Information

The fix is committed to the mainline Linux kernel and stable trees. Reference commits: 54e02f5e32c52fb395f2ee02986a6c6d5608d22b, 55341d8a5a0f5853e70d46f5a55cf06007808f1d, e2543852152bcf9aeb57da17d9f9219f7df8aafb, and eb0eca7720662ba5847df1510e73801f7f473094. The patches validate client-supplied atime and mtime in the NFSv3 proc handlers and return NFS3ERR_INVAL for out-of-range nseconds. See the Linux kernel stable tree commit for the reference change.

Workarounds

Disable NFSv3 exports and migrate clients to NFSv4 where feasible, since the flaw is specific to the NFSv3 setattr and create paths.
Limit NFSv3 access to trusted, managed clients that do not send malformed RPC payloads.
Where possible, mount NFS-exported filesystems with reduced timestamp granularity settings that avoid s_time_gran == 1 behavior until patched kernels are deployed.

bash

# Verify running kernel version and check for nfsd module
uname -r
lsmod | grep nfsd

# Restrict NFSv3 exports to trusted subnets in /etc/exports
# Example: /export 10.0.0.0/24(rw,sync,no_subtree_check)
exportfs -ra

# Optionally disable NFSv3 and enforce NFSv4 only
# In /etc/nfs.conf under [nfsd]:
# vers3=n
# vers4=y
systemctl restart nfs-server