Look up another CVE · open CVE-2026-89687 in the interactive tracker
CVE-2026-89687
nfsd: ensure nfsd_file_do_acquire() does not use a non-opened file
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem fs/nfsd. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-89687 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
->atomic_open is permitted to return success without actually opening the file. It indicates this by calling finish_no_open(). This means dentry_create() can return a file which hasn't been opened. This is extremely unlikely as ->atomic_open handlers typically use finish_no_open() only for already existing files, and dentry_create() isn't called in that case, and the parent being locked should prevent races. However out of an abundance of caution it seems wise to teach nfsd to only use the file returned by dentry_create() if FMODE_OPENED is set, indicating that it has in fact been opened.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
fs/nfsd/filecache.c
- What this is
- KERNEL NFSD, SUNRPC, AND LOCKD SERVERSMAINTAINERS section matched on fs/nfsd/ · linux-nfs@vger.kernel.org · Supported
- Kernel module
- nfsd
Check it on the machine
grep -w CONFIG_NFSD /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w nfsdPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_NFSD
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 7.5 high
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.49%, higher than 40.6% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- fs/nfsd
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 7.0 | 7.2.4 | a95a1cffacd0 |
| 7.0 | 7.3 | 5859cc01fee0 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- nfsd is a network NFS server. The bug is in the NFSv4 OPEN+CREATE path (nfsd4_vfs_create → dentry_create → nfsd_file_acquire_opened), reached by a remote client sending COMPOUND operations over TCP/2049.
- AC:LAttack complexity, low
- Filesystems whose ->atomic_open creates then calls finish_no_open (notably FUSE when FUSE_CREATE is unimplemented) reliably return an unopened struct file; the attacker only sends a normal OPEN with CREATE and does not depend on an uncontrolled race.
- PR:NPrivileges required, none
- Default nfsd deployments accept AUTH_SYS, which does not cryptographically authenticate the peer. An unauthenticated network attacker who can reach a writable export can spoof a UID and issue OPEN+CREATE with no credentials.
- UI:NUser interaction, none
- Exploitation uses only attacker-sent NFSv4 requests (clientid/session setup, PUTFH, OPEN with CREATE). No victim action such as mounting a filesystem or opening a file is required.
- S:UScope, unchanged
- Impact is a kernel oops in the nfsd worker on the host. That is denial of service within the same kernel security authority, not a VM, IOMMU, or sandbox escape.
- C:NConfidentiality impact, none
- The unused file is allocated via alloc_empty_file with f_op, f_mapping, and f_inode set to NULL. Later use is a NULL-pointer dereference that oopses and does not provide a read primitive or information disclosure.
- I:NIntegrity impact, none
- This is not a use-after-free, OOB write, or type confusion; the struct file is valid but never opened, so f_op stays NULL. There is no write primitive or control-flow hijack, only a crash.
- A:HAvailability impact, high
- Caching the unopened file NULL-dereferences f_mapping in nfsd_file_check_write_error on write opens, or f_op on later READ/WRITE/close (vfs_iocb_iter_read, filp_flush), oopsing the nfsd thread and denying NFS service.