SEPTEMBER 13, 2026
Live Feed
Back to database
Case File

CVE-2026-89551

CRITICAL · CVSS 9.8 EPSS 0.46%

Source: NVD + CISA KEV + EPSS · Published 2026-09-11 · Last synced 2026-09-13

CyberRota Analysis

AI-Generated

The vulnerability affects the Linux kernel's SUNRPC implementation, specifically in the xdr_buf_trim() function, where improper handling of buffer lengths can lead to an underflow condition. This flaw allows for potential exploitation, as it can cause the buffer length to wrap around to a large value, impacting the integrity of data processed by downstream XDR decoders. Organizations using affected Linux kernel versions should prioritize patching this vulnerability to mitigate risks associated with data corruption and potential denial-of-service scenarios.

CVE
CVE-2026-89551
Severity
CRITICAL
CVSS
9.8
EPSS
0.46%
Linux

Original NVD Description

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.