GPU VulnDB

Database/Control plane, storage & DevOps

Linux nfsd: unvalidated NFSv3 nseconds corrupts on-disk timestamps on ext4 and XFS

UnscoredCVE-2026-89666Control plane, storage & DevOpscurated

Impact

An NFSv3 client can send SETATTR, CREATE, MKDIR, SYMLINK or MKNOD with an atime or mtime whose nseconds field exceeds NSEC_PER_SEC. Nothing in the setattr path clamps it: timestamp_truncate() leaves it alone on nanosecond-granularity filesystems and the inode setters store it verbatim. ext4's ext4_encode_extra_time() then shifts tv_nsec into the 32-bit extra field, overflowing it and clobbering the seconds-epoch bits, so the stored year is wrong on read-back; XFS with bigtime mis-stores it the same way. Any tenant with write access to a shared dataset export can silently corrupt on-disk metadata that survives reboot and propagates into backups, and incremental sync tools that key on mtime will behave unpredictably afterwards.

Who can reach it

Any client that can mount the NFSv3 export with write permission. No server-local access needed; only normal export authentication applies.

What to do

Upgrade to a stable kernel containing the referenced commits and reboot the NFS server; drain or fail over clients first since knfsd cannot be restarted in place for a kernel fix. Already-corrupted timestamps are not repaired by the patch and must be found and corrected separately. The record names commits, not fixed release numbers.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.