CVE-2026-89687: nfsd: ensure nfsd_file_do_acquire() does not use a non-opened file
In the Linux kernel, the following vulnerability has been resolved:
nfsd: ensure nfsdfiledoacquire() does not use a non-opened file
->atomicopen is permitted to return success without actually opening the file. It indicates this by calling finishnoopen(). This means dentrycreate() can return a file which hasn't been opened. This is extremely unlikely as ->atomicopen handlers typically use finishnoopen() only for already existing files, and dentrycreate() 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 dentrycreate() if FMODEOPENED is set, indicating that it has in fact been opened.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In nfsd, ensure nfsd_file_do_acquire() does not use a non-opened file; only use the file returned by dentry_create() if FMODE_OPENED is set, and use finish_no_open() only for already existing files.
Event History
Frequently Asked Questions
How likely is this issue to be encountered in practice?
The affected path is described as extremely unlikely to occur. Typical atomic_open handlers use finish_no_open() only for files that already exist, while dentry_create() is not normally called for that case, and parent-directory locking should prevent races.
What condition leads to the unsafe file use?
An atomic_open handler must report success while not actually opening the file, using finish_no_open(). If dentry_create() returns that file, nfsd could use it even though it lacks the FMODE_OPENED state.
What does the fix change?
The fix makes nfsd use a file returned by dentry_create() only when FMODE_OPENED is set. This verifies that the file was actually opened before it is used.