In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Reject krb5 v2 wrap tokens with oversized ec field
gss_krb5_unwrap_v2() sets buf->len to a logical
length, which can be much smaller than head[0].iov_len
(the allocated receive-page capacity). It then calls
xdr_buf_trim() with a trim length derived from the 16-bit
"extra count" (ec) field in the Kerberos v2 token header.
The ec field is authenticated by the post-decrypt memcmp()
against the encrypted header copy, so a randomly-mutated
value is rejected. However, any peer holding a valid GSS
context can legitimately encrypt a token whose ec exceeds
the plaintext length. Per RFC 4121, such a token is
structurally malformed.
Although xdr_buf_trim() now clamps the buf->len subtraction
to avoid unsigned underflow, the buffer is still left in a
semantically invalid state (zero length, inconsistent iov
lengths) when ec is oversized.
Reject these tokens before calling xdr_buf_trim(), giving
callers a well-defined GSS_S_DEFECTIVE_TOKEN error and
keeping the xdr_buf internally consistent. The wrapped blob
begins at a nonzero offset -- both callers pass len as
offset + opaque_len -- so buf->len still counts the offset
bytes that precede the blob. Compare the trim length
against the remaining wrapped segment, buf->len - offset,
rather than the whole buffer; comparing against buf->len
alone leaves an offset-wide window in which an oversized ec
passes the test and xdr_buf_trim() cuts into the bytes ahead
of the blob.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 9.8
AV:N - gss_krb5_unwrap_v2() is reached from nfsd RPCSEC_GSS privacy unwrap on TCP/2049 and from the NFS client's gss_unwrap_resp_priv() on every krb5p reply, so a remote NFS peer delivers the oversized-ec wrap token over the network.
AC:L - A peer holding the GSS session keys can encrypt a RFC 4121 wrap token whose authenticated ec exceeds the plaintext; decrypt and the header memcmp succeed, then xdr_buf_trim() runs with that chosen length and no race or layout outside attacker control.
PR:N - A malicious or compromised NFS server that already shares a krb5p GSS context needs no account or capability on the victim client; ordinary krb5p replies and NFSv4.0 GSS callbacks are processed without local privileges on that host.
UI:N - Once a krb5p NFS mount exists, the client unwraps every privacy-protected reply and NFSv4.0 GSS callback with no further mount, click, or open; idle revalidations and server-driven callbacks are sufficient.
S:U - The corrupted xdr_buf and subsequent XDR decode and shift run in the host kernel that processed the RPC and do not cross a VM, IOMMU, or sandbox boundary.
C:H - An oversized ec makes xdr_buf_trim() underflow buf->len toward UINT_MAX, so later xdr_read_pages/xdr_shrink_bufhead use that length as a copy bound and read far past the receive buffer into adjacent kernel memory.
I:H - xdr_shrink_bufhead() then calls xdr_buf_head_shift_right() with a near-UINT_MAX length derived from the wrapped buf->len, an out-of-bounds write into kernel memory that can be used for control-flow hijacking.
A:H - Those unbounded XDR copies and the inconsistent xdr_buf (wrapped or zero length versus iov_lens) oops or panic nfsd or the NFS client, and the peer can repeat the request at will.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:N - gss_krb5_unwrap_v2() is reached from nfsd RPCSEC_GSS privacy unwrap on TCP/2049 and from the NFS client's gss_unwrap_resp_priv() on every krb5p reply, so a remote NFS peer delivers the oversized-ec wrap token over the network.
AC:L - A peer holding the GSS session keys can encrypt a RFC 4121 wrap token whose authenticated ec exceeds the plaintext; decrypt and the header memcmp succeed, then xdr_buf_trim() runs with that chosen length and no race or layout outside attacker control.
PR:N - A malicious or compromised NFS server that already shares a krb5p GSS context needs no account or capability on the victim client; ordinary krb5p replies and NFSv4.0 GSS callbacks are processed without local privileges on that host.
UI:N - Once a krb5p NFS mount exists, the client unwraps every privacy-protected reply and NFSv4.0 GSS callback with no further mount, click, or open; idle revalidations and server-driven callbacks are sufficient.
S:U - The corrupted xdr_buf and subsequent XDR decode and shift run in the host kernel that processed the RPC and do not cross a VM, IOMMU, or sandbox boundary.
C:H - An oversized ec makes xdr_buf_trim() underflow buf->len toward UINT_MAX, so later xdr_read_pages/xdr_shrink_bufhead use that length as a copy bound and read far past the receive buffer into adjacent kernel memory.
I:H - xdr_shrink_bufhead() then calls xdr_buf_head_shift_right() with a near-UINT_MAX length derived from the wrapped buf->len, an out-of-bounds write into kernel memory that can be used for control-flow hijacking.
A:H - Those unbounded XDR copies and the inconsistent xdr_buf (wrapped or zero length versus iov_lens) oops or panic nfsd or the NFS client, and the peer can repeat the request at will.
CVSS 3.1