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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-11T20:19:38.640Z",
  "pubdate": "2026-09-11T20:19:38.640Z",
  "executiveSummary": "This vulnerability is an integer underflow flaw residing in the SUNRPC (Sun Remote Procedure Call) implementation of the Linux kernel, specifically within the xdr_buf_trim function.\nThe issue arises from improper accounting of the xdr_buf length when trimming buffers, allowing an attacker to trigger an unsigned integer wrap-around.\nThe vulnerability affects the Linux kernel's handling of RPC data structures. By manipulating the discrepancy between the buffer's reported length and the actual iovec lengths, an attacker can cause the kernel to set an invalid, near-maximum length value for the RPC buffer.\nThe impact is significant: downstream XDR (eXternal Data Representation) decoders receive an authoritative length field that is incorrectly inflated, potentially leading to out-of-bounds memory access, kernel memory corruption, or system instability/crashes.\nExploitation requires the ability to influence the RPC message processing path, specifically via GSS-API/Kerberos unwrapping mechanisms (gss_krb5_unwrap_v2).\nSuccessful exploitation allows for the subversion of data decoding processes, which could lead to arbitrary kernel memory reads or service disruption.",
  "technicalDetails": "The vulnerability exists in the xdr_buf_trim() function, which is designed to remove a specified number of bytes from the tail of an xdr_buf structure. The function iterates through the head, pages, and tail iovecs to perform this truncation.\nThe root cause is a logic error in the final length calculation at the 'fix_len' label within xdr_buf_trim(). While the function correctly uses min_t() to ensure it does not remove more data than resides in individual buffer sections, it performs an unsigned subtraction (buf->len -= (len - trim)) without verifying if the calculated decrement exceeds the current buf->len value.\nIn certain scenarios, such as when processing GSS-API Kerberos tokens via gss_krb5_unwrap_v2, the buf->len may be explicitly set to a wire-derived value that is significantly smaller than the cumulative size of the iovec sections. When the subsequent call to xdr_buf_trim() occurs, the 'len - trim' calculation produces a value larger than the current buf->len.\nBecause buf->len is an unsigned integer, subtracting a larger value from a smaller one causes an integer wrap-around (underflow), resulting in a value close to UINT_MAX. This corrupted length is then stored back into the buf->len field.\nThis corrupted length field serves as the authoritative boundary for all downstream XDR decoders. When the kernel proceeds to parse the RPC data, the decoders rely on this inflated buf->len, believing there is a massive amount of valid data available to read. This leads to out-of-bounds reads, as the decoders will attempt to process memory well beyond the legitimate end of the buffer.\nThe attack flow involves triggering a specific kernel code path where buf->len is manually reduced (e.g., stripping headers during GSS-API unwrapping). By crafting a packet that satisfies the buffer accounting logic but results in a mismatch between the reported length and the physical memory backing the buffer, an attacker can force the kernel to enter an unstable memory-read state.\nThe impact extends to potential exploitation of the XDR parsing logic, which, once tricked into reading out-of-bounds, may expose kernel memory contents to the caller or cause a system panic due to page faults during unauthorized memory access."
}