Cloudanix VulnDB

CVE-2026-89551

Critical · 9.8

CVSS

9.8

EPSS

0.5%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A flaw in the Linux kernel's handling of network messages can let an attacker on the network crash the system or take full control without any login.

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

What it actually does

Unsigned underflow in xdr_buf_trim allows buf->len to wrap to near UINT_MAX when a small wire-derived length is recorded while iov_lens remain large; the corrupted length then propagates as the authoritative bound into all downstream XDR decoders, enabling memory corruption.

Why it matters to the business

Remote attackers can crash or potentially execute code inside the kernel on systems exposing RPC services that use Kerberos-wrapped GSS, leading to denial of service or full host compromise; widespread exposure exists across Linux distributions using SUNRPC.

How an attack unfolds

An attacker sends a crafted Kerberos V2-wrapped RPC message that reaches gss_krb5_unwrap_v2 with buf->len set smaller than the sum of the iov_lens; the subsequent xdr_buf_trim call performs an unchecked subtraction that wraps buf->len, after which any XDR decoder uses the huge value and reads or writes out of bounds.

How to fix it

Apply the upstream kernel patch that changes the final accounting line to buf->len -= min_t(unsigned int, buf->len, len - trim); rebuild and deploy the fixed kernel on all affected systems; prioritize patching any hosts that expose NFS or other SUNRPC services.

How to confirm the fix worked

Verify the presence of the clamp using min_t in xdr_buf_trim after the fix_len label; confirm that buf->len never exceeds the sum of its component iov_lens after any GSS unwrap path; test with crafted small-length GSS tokens that previously triggered wrap.

Typical attack path

  1. Establish network reachability to an RPC endpoint configured for GSS/Kerberos
  2. Craft and send a GSS-wrapped message that triggers the specific head/trail length adjustments in gss_krb5_unwrap_v2
  3. Force xdr_buf_trim to execute the underflowing subtraction at the fix_len label
  4. Abuse the resulting huge buf->len value in subsequent XDR decoding to corrupt kernel memory

How to detect it

Search kernel logs and audit trails for SUNRPC or GSS-related oops, warnings about invalid XDR lengths, or unexpected large buf->len values immediately after GSS unwrap operations; correlate with inbound RPC traffic containing Kerberos tokens.

What your security team should do

  • Patch all Linux kernels to the version containing the xdr_buf_trim clamp fix within the next 48 hours
  • Restrict exposure of GSS-authenticated RPC endpoints to trusted networks until patches are applied
  • Monitor for anomalous XDR length values or kernel oops in SUNRPC/GSS paths
  • Review and reduce attack surface by disabling Kerberos-wrapped RPC services where not required

The record

In the Linux kernel, the following vulnerability has been resolved: SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow xdr_buf_trim() trims `len` bytes from the tail of an xdr_buf by walking the tail, pages, and head iovecs. Each per-section step uses min_t() so it never removes more bytes than that section holds, but the final accounting at the fix_len label subtracts the total bytes actually consumed from buf->len without any clamp: fix_len: buf->len -= (len - trim); When the caller has set buf->len to a value smaller than the sum of the iov_lens, (len - trim) can exceed buf->len and the unsigned subtraction wraps to near UINT_MAX. gss_krb5_unwrap_v2() reaches xdr_buf_trim() in exactly that state: buf->head[0].iov_len -= GSS_KRB5_TOK_HDR_LEN + headskip; buf->len = len - (GSS_KRB5_TOK_HDR_LEN + headskip); xdr_buf_trim(buf, ec + GSS_KRB5_TOK_HDR_LEN + tailskip); buf->len is a small wire-derived value while the iov_lens are at page scale, so the per-section loops legitimately consume far more bytes than buf->len records. The wrapped buf->len then propagates as the authoritative stream bound into every downstream XDR decoder. Fix by clamping the decrement so buf->len bottoms out at zero: buf->len -= min_t(unsigned int, buf->len, len - trim); On the normal path where the iov_lens sum to buf->len, (len - trim) is always <= buf->len and the result is identical to before. No callers change behavior outside the underflow case.

Affected packages

Ecosystem Package Introduced Fixed