CVE-2026-89713

NFSD: check truncate permission under inode lock

CRITICAL
9.1
CVSS Score
Published: September 11, 2026 at 07:46 PM UTC
Updated: October 30, 2026 at 01:20 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
CRITICAL9.1
Exploit prediction
EPSS 0.7%
SSVC
No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: NFSD: check truncate permission under inode lock nfsd_setattr() checks whether a size update needs NFSD_MAY_TRUNC before it takes inode_lock(). The comparison uses the file size sampled by that unlocked read, but the actual ATTR_SIZE update is applied later under inode_lock() by notify_change(). This leaves a TOCTOU window for append-only files. If a client sends a SETATTR that does not shrink the file at the time of the unlocked sample, a concurrent append can extend the file before nfsd_setattr() takes inode_lock(). notify_change() then applies a real truncation without the NFSD_MAY_TRUNC check that rejects IS_APPEND(inode). The VFS truncate syscall paths perform their own append-only checks before calling notify_change(), so NFSD must make this decision against the locked size it is about to change. Split the write-count acquisition from the truncation permission check. Keep get_write_access() before the locked setattr work, then recheck whether the requested size is below i_size_read(inode) after inode_lock() has been acquired and before notify_change(ATTR_SIZE). This also avoids the plain unlocked inode->i_size load.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

3.16.443.2.893ee4f442e5b37a537297b812557b1163f96b53994.10.24.114.4.534.9.14604a3c407026d6162d15300478e63f901e435efc783112f7401ff449d979530209b3f6c2594fdb4e982898d7f97a35447403c3fcecc0d96c646ce101a3c6cbc4eac4473ed5461d5faae2794d3e5c0e44cc4d5dc73841b98d33cdfb9822d70b0aac4beca5
Vendor states this is fixed in 3afa17d93ba8c925f49370c816c6dae5112d8c24 (fixed)
Vendor states this is fixed in 44086254479035de42ca3d286ecf25521d4e6325 (fixed)
Vendor states this is fixed in b778e0e0a16759f22a70579c3cf8d254a40d4a7f (fixed)
Vendor states this is fixed in d8352da196349182e1afd5a93308256cddc0a97d (fixed)
Affected range stops below 3.17, so it looks safe — our inference, not a vendor statement
Affected range stops below 3.3, so it looks safe — our inference, not a vendor statement
Affected range stops below 4.10, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 4.11 (unaffected)
Affected range stops below 4.5, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 6.12.109 (unaffected)
Vendor states this is fixed in 6.18.50 (unaffected)
Vendor states this is fixed in 6.6.160 (unaffected)
Vendor states this is fixed in 7.2.4 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

SSVC — Action Prioritization

SSVCNo known exploitAutomatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

9.1CRITICALLinux
Vector?

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card