Cloudanix VulnDB

CVE-2026-89673

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A server bug can accidentally send tiny pieces of its own internal memory to certain file-sharing clients instead of the expected reply data.

Exploitation
Remote Authenticated
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Information Disclosure
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw causes nfsd4_ff_encode_getdeviceinfo to reserve 16 + netid_len + addr_len bytes for da_addr_body while xdr_encode_opaque actually writes 8 + round_up(netid_len,4) + round_up(addr_len,4) bytes, sending 2-8 bytes of stale kernel reply-page memory to the client on every flexfile GETDEVICEINFO response.

Why it matters to the business

NFS servers may leak small fragments of kernel memory contents to any client that requests flexfile device information, potentially exposing sensitive data with low likelihood of exploitation given the narrow trigger and lack of known campaigns.

How an attack unfolds

An attacker mounts an NFS share from a vulnerable server, issues NFSv4.1 GETDEVICEINFO operations requesting flexfile layout information, and inspects the over-long da_addr_body fields in the replies to extract whatever stale page content was appended.

How to fix it

Apply the upstream kernel commit that replaces the length calculation with xdr_align_size() calls, or update to any later kernel release that includes the fix for this XDR padding mismatch.

How to confirm the fix worked

Confirm the nfsd source contains the xdr_align_size() usage in ff_encode_getdeviceinfo and that the resulting da_addr_body length exactly matches the bytes emitted by xdr_encode_opaque for netid and addr strings.

Typical attack path

  1. Establish an NFSv4.1 mount to a target server that supports flexfiles
  2. Send repeated GETDEVICEINFO requests for flexfile device info
  3. Parse the oversized da_addr_body opaque data in each reply
  4. Scan extracted bytes for useful kernel memory artifacts

How to detect it

Review NFS server logs and network captures for unusually large or malformed GETDEVICEINFO responses; examine client-side packet traces for da_addr_body lengths that exceed expected XDR sizes by 2-8 bytes.

What your security team should do

  • Prioritize kernel updates on all NFS servers that export flexfile layouts
  • Monitor EPSS and KEV status; current values indicate low immediate risk
  • Restrict NFSv4.1 flexfile access to trusted clients until patched

The record

In the Linux kernel, the following vulnerability has been resolved: nfsd: fix XDR padding calculation in ff_encode_getdeviceinfo nfsd4_ff_encode_getdeviceinfo() computes the da_addr_body reservation as 16 + netid_len + addr_len, but the subsequent xdr_encode_opaque() calls emit 8 + round_up(netid_len, 4) + round_up(addr_len, 4) bytes. The mismatch means the declared da_addr_body length exceeds the actual encoded data by 2-8 bytes on every flexfile GETDEVICEINFO reply, leaking stale reply-page content to the client and mis-aligning the subsequent version list decode. Use xdr_align_size() for each string length to match what xdr_encode_opaque() actually writes.

Affected packages

Ecosystem Package Introduced Fixed