Linux NFSD: NFSv2 SETATTR/CREATE useconds wrap to a bogus tv_nsec on 32-bit servers

CVSS 8.2CVE-2026-89665Kernel, userspace & hypervisorcurated

Impact

The NFSv2 sattr decoder multiplies a u32 useconds value by NSEC_PER_USEC into an unsigned long. On ILP32 that is 32 bits, so an out-of-range value such as 4294968 wraps and yields a small in-range tv_nsec - corruption that happens during decode, before any proc function can range-check it. A second issue is real on all word sizes: the Sun 'set to current server time' convention (useconds == 1000000) was only honoured in the mtime block, so a client putting it in the atime field alone pushed an out-of-range tv_nsec of 10^9 to the filesystem with ATTR_ATIME_SET still set. Impact is timestamp integrity on NFS-exported data, not code execution. Practically this is near-unreachable on a datacenter fleet: it needs a 32-bit kernel and NFSv2 enabled on the export, neither of which is normal on a GPU node's storage tier.

Who can reach it

An NFS client sending a v2 SETATTR or CREATE with an out-of-range useconds field, against a server that still serves NFSv2. The wrap itself requires a 32-bit (ILP32) kernel; the atime Sun-convention bug does not.

What to do

Apply the stable fix, which rejects useconds greater than 1000000 in the decoder and applies the Sun convention symmetrically in the atime block, and reboot the node. Disabling NFSv2 on exports removes exposure without a reboot and is the right answer for most fleets anyway. No fixed version is stated in the record.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-89665 https://git.kernel.org/stable/c/1195483965a5f63d2dde18054ec7e50a23b9071c https://git.kernel.org/stable/c/26709c8ffe73772eb69e68d553ac71d91228dccc https://git.kernel.org/stable/c/a937dd1aa2d92291fe0a1860d17e90d8f206cd22

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.