← All Advisories
Reported from OT-Advisories.com as of

CVE-2026-89665

Last refreshed2026-10-17

Status: UPDATED  |  Advisory ID: CVE-2026-89665

Key Details

CVECVE-2026-89665
CVSS Score / Version
8.2 (High) / CVSS v3.1
Updated2026-10-16
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L
CVSS Prose
attack vector is network; attack complexity is low; privileges required is none; user interaction is none; scope is unchanged; confidentiality impact is none; integrity impact is high; availability impact is low.
Affected products
Linux Kernel

Affected Products, Subsystems & Sectors

VendorProductAffected VersionsPatch Status
LinuxLinux Kernel
SubsystemsOT Supporting Infrastructure
SectorsAll Sectors

What to Know

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

nfsd: reject out-of-range useconds in NFSv2 SETATTR/CREATE

The NFSv2 sattr decoder converts the wire useconds to nanoseconds in

svcxdr_decode_sattr():

iap->ia_atime.tv_nsec = tmp2 * NSEC_PER_USEC;

tmp2 is a u32 and NSEC_PER_USEC is 1000, so the product is computed in

unsigned long. On ILP32 that is 32 bits, and an out-of-range useconds

value such as 4294968 wraps to tv_nsec == 704. The corruption therefore

happens during decode, before any proc function can inspect the value,

and a later range check on tv_nsec would see an in-range result and

accept it. Rejecting in the decoder yields an RPC GARBAGE_ARGS reply.

NFSv2 defines no NFSERR_INVAL, so there is no NFS-level status to return

for a malformed time argument, and the check cannot move to the proc

function the way the v3/v4 nsec range checks do.

Guard the raw useconds before the multiplication and reject values

greater than 1000000. useconds == 1000000 is kept: it is the Sun

convention for "set to the current server time", and the in-tree Linux

NFSv2 client emits it in both the atime and the mtime field for a plain

touch / utimes(file, NULL) (see encode_sattr() and

xdr_encode_current_server_time() in fs/nfs/nfs2xdr.c). Rejecting 1000000

would turn that common operation into a hard decode failure for both

SETATTR and CREATE. 1000000 * NSEC_PER_USEC is 10^9, which does not wrap

on ILP32, so the Sun convention value passes through safely. Only

genuinely out-of-range values (> 1000000) are rejected. The atime and

mtime guards are therefore symmetric.

The decoder only applied the Sun convention in the mtime block, which

clears ATTR_ATIME_SET|ATTR_MTIME_SET when mtime useconds == 1000000. If a

client puts 1000000 in the atime field but not in the mtime field, the

atime block stored an out-of-range tv_nsec (10^9) and left ATTR_ATIME_SET

set, so the bogus value reached the filesystem. Apply the convention in

the atime block as well, clearing ATTR_ATIME_SET so the server uses its

current time and ignores the value. Only ATTR_ATIME_SET is cleared there.

The mtime block keeps its existing behavior, where 1000000 means "set

both atime and mtime to now".

[ cel: various tweaks, addenda, and clean-ups ] (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References

SourceReference
NVDhttps://nvd.nist.gov/vuln/detail/CVE-2026-89665
CVEhttps://www.cve.org/CVERecord?id=CVE-2026-89665
Report compilation © 2026 OT-Advisories.com  ·  CC BY 4.0  ·  Source materials remain the property of their respective publishers as cited.