CVE-2026-89666

In the Linux kernel, the following vulnerability has been resolved:

nfsd: reject out-of-range nseconds in NFSv3 SETATTR and create ops

A client can send an NFSv3 SETATTR, CREATE, MKDIR, SYMLINK or MKNOD

carrying an atime or mtime whose nseconds field is out of range. The

value is well-formed on the wire and decodes cleanly into a valid

uint32, but it is not a valid timespec64: tv_nsec must be less than

NSEC_PER_SEC.

Nothing in the setattr path clamps it. notify_change() runs the time

through timestamp_truncate(), which does not reduce tv_nsec below

NSEC_PER_SEC when the filesystem supports nanosecond granularity

(s_time_gran == 1), and the inode atime/mtime setters store it verbatim

(only ctime is normalized, via inode_set_ctime_to_ts()). The

un-normalized value then corrupts on-disk metadata: ext4's

ext4_encode_extra_time() shifts tv_nsec left by EXT4_EPOCH_BITS, which

overflows the 32-bit extra field and clobbers the seconds-epoch bits, so

the stored seconds (and thus the year) are wrong on read-back. XFS with

bigtime mis-stores the timestamp for the same reason.

Validate the client-supplied atime/mtime in the proc handlers and return

NFS3ERR_INVAL before anything is changed. RFC 1813 lists NFS3ERR_INVAL

for SETATTR and describes it as the error for a value the server 'can

not store ... in its own representation'; the client maps it to EINVAL.

Checking in the proc handlers, rather than in nfsd_setattr(), keeps the

rejection in front of object creation. The create operations create the

object before nfsd_create_setattr() runs, so a late failure would leave

the new object behind and turn a non-idempotent request into a namespace

change that reports failure. The check is therefore done up front, for

the create operations before the object is created.

tv_nsec is a long, so the comparison casts it to unsigned long (the same

width) rather than to u32, matching timespec64_valid(). A u32 cast would

truncate on 64-bit; the unsigned long cast also rejects a value that

became negative when an out-of-range u32 wire nseconds was assigned to a

32-bit long.

Only client-supplied times are checked: SET_TO_SERVER_TIME requests

carry no client value. The sattrguard3 ctime is deliberately left alone:

an out-of-range guard simply never matches the object's ctime and yields

NFS3ERR_NOT_SYNC via the existing guardtime comparison, which is the

protocol-correct outcome rather than rejecting the request.