Cloudanix VulnDB

CVE-2026-89699

High · 7.5

CVSS

7.5

EPSS

0.5%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A problem in how network file servers handle certain file creation requests could let attackers use up server memory and interrupt file access for everyone.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The flaw allows nfsd4_decode_create() to accept unbounded cr_datalen values from the wire for NF4LNK symlink targets, triggering kmalloc allocations up to maximum RPC payload size (several MiB) that persist until COMPOUND teardown, even though the VFS later rejects them with ENAMETOOLONG.

Why it matters to the business

NFS servers can suffer memory exhaustion and denial of service, disrupting file sharing and access for applications and users until the server is restarted or the workload subsides.

How an attack unfolds

An attacker sends crafted NFSv4 COMPOUND operations containing NF4LNK CREATE requests with oversized cr_datalen values; the server allocates large kernel buffers before length validation occurs, enabling repeated requests to exhaust memory resources.

How to fix it

Apply upstream kernel patches that add early rejection of cr_datalen == 0 with nfserr_inval and cr_datalen > NFS4_MAXPATHLEN with nfserr_nametoolong in nfsd4_decode_create(); update to a kernel containing this fix.

How to confirm the fix worked

Confirm the fix by inspecting the nfsd4_decode_create() implementation for the new length checks against NFS4_MAXPATHLEN, or verify the running kernel version includes the resolution commit.

Typical attack path

  1. Establish an NFSv4 mount or send unauthenticated COMPOUND requests to the target server
  2. Issue NF4LNK CREATE operations with cr_datalen set to values up to several MiB
  3. Repeat requests rapidly to trigger cumulative kernel memory allocations before compound teardown

How to detect it

Review NFS server logs and network captures for COMPOUND operations with NF4LNK creates carrying unusually large cr_datalen values; correlate with kernel memory allocation patterns or OOM events.

What your security team should do

  • Prioritize patching NFS servers to a kernel containing the symlink length validation
  • Monitor NFS server memory usage for sudden spikes correlated with client activity
  • Consider rate-limiting or access controls on NFSv4 if immediate patching is not feasible

The record

In the Linux kernel, the following vulnerability has been resolved: nfsd: validate symlink target length in NFSv4 CREATE nfsd4_decode_create() accepts an unbounded cr_datalen from the wire for NF4LNK symlink targets, allowing a client to force a kmalloc of up to the maximum RPC payload size (several MiB) per COMPOUND op that persists until compound teardown. The VFS rejects oversized targets with ENAMETOOLONG, but the allocation has already occurred. Reject cr_datalen == 0 early with nfserr_inval and cr_datalen greater than NFS4_MAXPATHLEN (PATH_MAX) with nfserr_nametoolong to bound the allocation.

Affected packages

Ecosystem Package Introduced Fixed