CVE-2025-68242

What it actually does

The nfs_setattr function omits verification of the inode UID against the caller's fsuid when delegated timestamps are enabled, allowing unauthorized atime/mtime modifications via NFSv4.2.

Why it matters to the business

Systems relying on NFS with delegated timestamps risk unauthorized file timestamp changes that can disrupt auditing, compliance checks, and integrity monitoring in shared storage environments; the low EPSS and lack of KEV listing indicate limited active threat but patching remains necessary given the 2025 publication.

How an attack unfolds

An attacker mounts an NFS share with delegated timestamps enabled, then issues utime or utimes calls as a non-matching user such as nobody; because nfs_setattr skips the UID/fsuid comparison the kernel accepts the request locally instead of forwarding it to the server for authorization.

How to fix it

Update affected Linux kernels to the commit b2e4cda71ed062c87573b016d2d956a62f4258ed or later; upgrade argocd-image-updater-fips to 0.15.2-r3. Rebuild and redeploy any downstream packages that embed the vulnerable NFS client code.

How to confirm the fix worked

Confirm the presence of the UID/fsuid check inside nfs_setattr after applying the fix; re-execute the LTP utimes01 and utime06 test suites on an NFS mount with delegated timestamps; verify kernel version or git commit contains b2e4cda71ed062c87573b016d2d956a62f4258ed.

Typical attack path

1. Configure and mount an NFSv4.2 share with delegated timestamps permitted
2. Obtain or assume a non-root user identity (for example nobody)
3. Invoke utime/utimes syscalls against files owned by other UIDs
4. Observe successful timestamp updates without server-side permission checks

How to detect it

Review NFS server and client audit logs for utime or setattr operations performed by users whose UID does not match the target inode owner; correlate with process execution of LTP-style test binaries or unexpected timestamp changes on files owned by other accounts.

What your security team should do

• Apply the kernel patch or distribution update containing b2e4cda71ed062c87573b016d2d956a62f4258ed within standard change windows
• Disable delegated timestamps on NFS exports until patches are deployed if the workload permits
• Include NFS-related LTP tests in regression suites for future kernel updates
• Review NFS export configurations for unnecessary no_root_squash or delegated timestamp settings