--- id: CVE-2026-89666 title: 'nfsd: reject out-of-range nseconds in NFSv3 SETATTR and create ops' summary: |- 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… severity: high cvss: 7 cvssVector: 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H' cvssSource: vendor cwe: - CWE-190 vendor: Linux product: Linux affected: - >- Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 98fc1d21a7b80324ba64b949ac6bcc00364dd068 - >- Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 55341d8a5a0f5853e70d46f5a55cf06007808f1d - >- Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 54e02f5e32c52fb395f2ee02986a6c6d5608d22b - >- Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < e2543852152bcf9aeb57da17d9f9219f7df8aafb - >- Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < eb0eca7720662ba5847df1510e73801f7f473094 - Linux 2.6.12 published: '2026-09-11' updated: '2026-10-21' sourceUpdated: '2026-10-21T12:48:15.619Z' source: CVEORG sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-89666' references: - url: 'https://git.kernel.org/stable/c/98fc1d21a7b80324ba64b949ac6bcc00364dd068' - url: 'https://git.kernel.org/stable/c/55341d8a5a0f5853e70d46f5a55cf06007808f1d' - url: 'https://git.kernel.org/stable/c/54e02f5e32c52fb395f2ee02986a6c6d5608d22b' - url: 'https://git.kernel.org/stable/c/e2543852152bcf9aeb57da17d9f9219f7df8aafb' - url: 'https://git.kernel.org/stable/c/eb0eca7720662ba5847df1510e73801f7f473094' - url: >- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89666.json - url: 'https://access.redhat.com/security/cve/CVE-2026-89666' - url: 'https://bugzilla.redhat.com/show_bug.cgi?id=2532519' - url: 'https://www.cve.org/CVERecord?id=CVE-2026-89666' - url: 'https://nvd.nist.gov/vuln/detail/CVE-2026-89666' - url: >- https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-89666.mbox tags: - cve.org - csaf - vex - red-hat epss: 0.00168 epssPercentile: 0.06156 ingestedAt: '2026-09-14T11:11:19.885Z' --- ## Overview 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. ## Affected - `Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 98fc1d21a7b80324ba64b949ac6bcc00364dd068` - `Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 55341d8a5a0f5853e70d46f5a55cf06007808f1d` - `Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < 54e02f5e32c52fb395f2ee02986a6c6d5608d22b` - `Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < e2543852152bcf9aeb57da17d9f9219f7df8aafb` - `Linux >= 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 < eb0eca7720662ba5847df1510e73801f7f473094` - `Linux 2.6.12` ## Remediation Refer to the linked advisories for vendor-supplied fixes and affected version ranges. ## Vendor advisories - **Red Hat VEX** · Moderate · affected: Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 9, Red Hat OpenShift Container Platform 4 · no fix planned: Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8, … · updated 2026-09-15 · [vex](https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89666.json)