Cloudanix VulnDB

CVE-2026-89695

High · 7.5

CVSS

7.5

EPSS

0.5%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in the Linux kernel's file-sharing server lets remote attackers overwhelm the machine with CPU work by sending specially crafted requests, disrupting access to shared files.

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

What it actually does

Unbounded CPU consumption in the NFS server due to an O(n²) bubble sort on an attacker-supplied POSIX ACL entry count that is never capped against NFS_ACL_MAX_ENTRIES before posix_acl_alloc and sort_pacl_range are called.

Why it matters to the business

Attackers can remotely trigger high CPU load on any exposed NFS server, causing denial of service for file-sharing workloads and degrading overall system responsiveness until the malicious request completes.

How an attack unfolds

An attacker sends a crafted NFSv4 compound request containing a POSIX ACL with a deliberately large entry count; nfsd4_decode_posixacl reads the uncapped u32 value and passes it directly to the quadratic sort, consuming excessive CPU in the server's request-processing path.

How to fix it

Apply the upstream kernel patch that rejects counts greater than NFS_ACL_MAX_ENTRIES with nfserr_inval and returns nfserr_jukebox on allocation failure; update to a Linux kernel release containing commit 5fc51dfc2eb1 plus the described fix.

How to confirm the fix worked

Confirm the patched kernel is running, then attempt an NFSv4 request with an ACL count exceeding NFS_ACL_MAX_ENTRIES and verify that nfserr_inval is returned without excessive CPU usage.

Typical attack path

  1. Establish an NFSv4 mount or send a compound request to the target nfsd
  2. Include a POSIX ACL XDR blob whose a_count exceeds NFS_ACL_MAX_ENTRIES
  3. Trigger nfsd4_decode_posixacl to allocate and sort the ACL
  4. Observe sustained high CPU utilization in the nfsd worker threads

How to detect it

Correlate high CPU in nfsd processes with inbound NFSv4 compound requests containing large POSIX ACL structures; inspect kernel logs for repeated memory-allocation or invalid-argument paths in the nfsd4_decode_posixacl function.

What your security team should do

  • Prioritize patching all systems exposing NFSv4 services
  • Restrict NFS access to trusted clients via firewall or export options until patched
  • Monitor nfsd CPU usage for sudden sustained spikes
  • Disable NFSv4 ACL support if not required

The record

In the Linux kernel, the following vulnerability has been resolved: nfsd: cap decoded POSIX ACL count to bound sort cost nfsd4_decode_posixacl() reads a u32 entry count off the wire and passes it straight to posix_acl_alloc() and sort_pacl_range(). The latter is an O(n^2) bubble sort, so a client-chosen count drives unbounded CPU in the server's compound processing path. nfsd4_decode_posixacl() xdr_stream_decode_u32(&count) /* uncapped u32 */ posix_acl_alloc(count, GFP_KERNEL) sort_pacl_range(*acl, 0, count - 1) /* O(n^2) bubble sort */ The encoder side in the same file already rejects ACLs whose a_count exceeds NFS_ACL_MAX_ENTRIES, but the decoder introduced in commit 5fc51dfc2eb1 ("NFSD: Add support for XDR decoding POSIX draft ACLs") omitted the symmetric check. Fix by rejecting a wire count greater than NFS_ACL_MAX_ENTRIES with nfserr_inval, before any allocation, so the sort is bounded by NFS_ACL_MAX_ENTRIES^2 comparisons. While we're in here, also fix the nfserr_resource return if posix_acl_alloc() fails. That's not a legal error code for v4.1+. Change it to return nfserr_jukebox as that's more appropriate for memory allocation failures.

Affected packages

Ecosystem Package Introduced Fixed