CVE-2026-89542
moderateOut-of-Bounds Read and Unsigned Underflow in Linux Kernel gss_krb5_unwrap_v2 (NFS Kerberos)
The Linux kernel's SUNRPC Kerberos token unwrap routine gss_krb5_unwrap_v2() reads the EC and RRC header fields at ptr+4 and ptr+6 before validating that the token is at least the 16-byte GSS header length, and its rotate_left() helper computes buf->len - base without verifying that base is within the buffer. An attacker who can deliver a crafted, shorter-than-16-byte or length-inconsistent GSS-Krb5 wrapped token into an RPCSEC_GSS exchange triggers an out-of-bounds kernel memory read, a potential u32 wrap and divide-by-zero in xdr_buf_subsegment, and an unsigned underflow of movelen that drives a ~UINT_MAX-byte memmove; a BUG_ON meant to catch the underflow is dead code (it reduces to min(A,B) > A and is always false). Successful exploitation yields information disclosure and memory corruption with total loss of confidentiality, integrity, and availability (CVSS 9.8, network, no privileges or user interaction). Systems affected are Linux hosts acting as NFS servers or clients using Kerberos-wrapped RPC (sec=krb5, krb5i, or krb5p) — reaching the vulnerable path requires an attacker positioned to inject a token, such as a malicious authenticated peer or an on-path manipulator of the RPC traffic. No public proof of concept exists, the flaw is not in CISA's KEV, and no exploitation has been observed.
What to do: Patch to a kernel build containing the SUNRPC fix that adds length validation guards before the EC/RRC reads and the xdr_buf_subsegment call, replacing the dead BUG_ON with a GSS_S_DEFECTIVE_TOKEN return; prioritize NFS servers and clients configured with sec=krb5, krb5i, or krb5p. Until patched, restrict NFS exports to trusted clients and keep port 2049 and related RPC services off untrusted networks, and check logs for kernel oopses, divide-by-zero faults, or BUG reports in the sunrpc/gss_krb5 path as signs of malformed-token probing.
| Linux kernel (SUNRPC/gss_krb5 unwrap v2, RPCSEC_GSS Kerberos) | Kernel versions carrying the vulnerable gss_krb5_unwrap_v2() implementation prior to the fixing commit; no specific version range was stated in the advisory |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: harden gss_krb5_unwrap_v2 against short tokens gss_krb5_unwrap_v2() reads the EC and RRC header fields at ptr+4 and ptr+6 before validating that the token is at least GSS_KRB5_TOK_HDR_LEN (16) bytes long, and its rotate_left() helper passes buf->len - base to xdr_buf_subsegment() without verifying that base len. When a caller hands in a sub-16-byte token, or a token whose declared len leaves base past the end of the buffer, three distinct failures follow: gss_krb5_unwrap_v2(offset, len, buf) ptr = buf->head[0].iov_base + offset ec = *(ptr + 4) /* OOB read on short head */ rrc = *(ptr + 6) /* OOB read on short head */ rotate_left(offset + 16, buf, rrc) xdr_buf_subsegment(buf, &subbuf, base, buf->len - base) /* u32 wrap when base > len */ _rotate_left(&subbuf, shift) shift %= buf->len /* divide-by-zero when base == len */ After decryption, the cleanup arithmetic has the same shape: movelen = min_t(unsigned int, buf->head[0].iov_len, len); movelen -= offset + GSS_KRB5_TOK_HDR_LEN + headskip; BUG_ON(offset + GSS_KRB5_TOK_HDR_LEN + headskip + movelen > buf->head[0].iov_len); The BUG_ON re-adds the value just subtracted, so it reduces to min(A, B) > A and is permanently false; it cannot catch the unsigned underflow of movelen, which then drives a ~UINT_MAX-byte memmove(). Add four defense-in-depth guards inside the unwrap core so it is safe regardless of what its callers validate: - reject tokens with len - offset len len is zero, so the shift %= buf->len modulo cannot fault; - replace the dead BUG_ON with a live check that returns GSS_S_DEFECTIVE_TOKEN before the movelen subtraction.
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
In the news0 stories
No ingested article mentions this CVE yet.