Cloudanix VulnDB

CVE-2026-89711

High · 8.2

CVSS

8.2

EPSS

0.4%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A server that shares files using NFS could crash when handling certain directory requests from clients, interrupting file access until the system is restarted or updated.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Flawed assumption in nfsd_mode_check allowed dentry objects lacking i_op->lookup to reach a code path that calls inode->i_op->lookup without a NULL check, enabling potential NULL pointer dereference during NFSD directory verification in reexport scenarios.

Why it matters to the business

Kernel panic or denial of service on NFS servers configured for reexport, leading to unplanned downtime and service disruption for clients relying on exported filesystems.

How an attack unfolds

An attacker sends crafted LOOKUP requests against an NFSD export of an NFS filesystem containing mountpoint or referral dentries; the server reaches nfsd_mode_check, skips the invalid WARN path, but without the nfserr_notdir guard would dereference a NULL lookup method pointer, crashing the kernel.

How to fix it

Update the Linux kernel to a version containing commit e75b23f9e323 or the follow-up removal of the WARN_ON_ONCE in nfsd_mode_check; ensure nfserr_notdir return remains in place for affected dentries.

How to confirm the fix worked

Confirm kernel source contains removal of the WARN_ON_ONCE call from nfsd_mode_check and that nfserr_notdir is still returned before the lookup_one_unlocked call; test NFSD reexport of NFS mounts containing mountpoints.

Typical attack path

  1. Identify NFSD instance exporting an NFS filesystem with mountpoints or referrals
  2. Send LOOKUP RPCs targeting such dentries
  3. Trigger nfsd_mode_check branch that assumes i_op->lookup always exists
  4. Cause NULL dereference in __lookup_slow when guard return is absent

How to detect it

Search kernel logs for oops or WARN messages mentioning nfsd_mode_check, d_can_lookup, or NULL pointer dereference during nfsd operations; examine audit logs for unusual LOOKUP RPC patterns against reexported NFS mounts.

What your security team should do

  • Prioritize kernel upgrade for all systems running NFSD with NFS reexports
  • Review nfsd export configurations to identify reexport usage
  • Monitor for kernel oops or NULL dereference panics referencing nfsd_mode_check or __lookup_slow

The record

In the Linux kernel, the following vulnerability has been resolved: NFSD: remove flawed WARN_ON_ONCE from nfsd_mode_check The header for commit e75b23f9e323 ("nfsd: check d_can_lookup in fh_verify of directories") details the assumption that justified adding the WARN_ON_ONCE to nfsd_mode_check(), that assumption is invalid (in the case of NFS reexport). When NFSD exports an NFS filesystem it is very possible for nfsd_mode_check() to encounter a @dentry that doesn't have i_op->lookup (see nfs_fhget()'s NFS_ATTR_FATTR_MOUNTPOINT and NFS_ATTR_FATTR_V4_REFERRAL handling, and d_flags_for_inode()). So remove nfsd_mode_check()'s WARN_ON_ONCE(). The nfserr_notdir return on that branch must stay. It guards the subsequent lookup_one_unlocked() -> __lookup_slow() path, which calls inode->i_op->lookup() with no NULL check, so returning nfserr_notdir is what keeps a client LOOKUP into such a @dentry from dereferencing a NULL method pointer.

Affected packages

Ecosystem Package Introduced Fixed