Cloudanix VulnDB

CVE-2025-40210

None

CVSS

—

EPSS

0.4%

Published

Nov 21, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's network file-sharing code lets an attacker send a specially crafted request that can crash or freeze servers used for file access.

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

What it actually does

The NFS server in the Linux kernel accepts an NFSv4 COMPOUND request whose header declares an arbitrarily large operation count, causing an unbounded vmalloc attempt for the operation array that fails with an out-of-memory error and leaves the connection or lease in an inconsistent state.

Why it matters to the business

NFS file servers can become unresponsive or crash when handling crafted requests, disrupting shared storage access for applications and users until the server is restarted.

How an attack unfolds

An attacker sends a single NFSv4 COMPOUND request containing an extremely large operation count in the header; the server attempts to allocate a correspondingly large array, triggering a vmalloc failure that may hang subsequent CLOSE operations or destabilize the lease state.

How to fix it

Upgrade the Linux kernel to version 6.17.8 or later, or apply the commit that restores the 200-operation cap on NFSv4 COMPOUND requests.

How to confirm the fix worked

Verify the running kernel version is at or above the fixed release; confirm the restored operation limit is present by inspecting the nfsd COMPOUND decoding path; test with pynfs COMP6 and CLOSE9 sequences to ensure they complete without hanging.

Typical attack path

  1. Establish an NFSv4 mount to the target server
  2. Craft a COMPOUND request with an oversized operation count in the header
  3. Send the request over the established connection
  4. Observe server-side allocation failure and subsequent hangs on legitimate operations

How to detect it

Search kernel logs for nfsd vmalloc failures that reference extremely large allocation sizes or COMPOUND operation arrays; correlate with NFSv4 connection resets or indefinite CLOSE hangs reported by clients.

  • nfsd: vmalloc error: size .* exceeds total pages
  • mode:0xdc0(GFP_KERNEL|__GFP_ZERO)

What your security team should do

  • Apply the kernel update to all NFS servers within the next maintenance window
  • Monitor nfsd logs for vmalloc errors mentioning COMPOUND operation arrays
  • Restrict NFSv4 access to trusted clients until patches are deployed
  • Review downstream kernel packages for the same fix once they are rebuilt

The record

In the Linux kernel, the following vulnerability has been resolved: Revert "NFSD: Remove the cap on number of operations per NFSv4 COMPOUND" I've found that pynfs COMP6 now leaves the connection or lease in a strange state, which causes CLOSE9 to hang indefinitely. I've dug into it a little, but I haven't been able to root-cause it yet. However, I bisected to commit 48aab1606fa8 ("NFSD: Remove the cap on number of operations per NFSv4 COMPOUND"). Tianshuo Han also reports a potential vulnerability when decoding an NFSv4 COMPOUND. An attacker can place an arbitrarily large op count in the COMPOUND header, which results in: [ 51.410584] nfsd: vmalloc error: size 1209533382144, exceeds total pages, mode:0xdc0(GFP_KERNEL|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0 when NFSD attempts to allocate the COMPOUND op array. Let's restore the operation-per-COMPOUND limit, but increased to 200 for now.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 0 6.17.8
Linux Kernel 6.17.0 6.17.8

Related vulnerabilities