In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: harden gss_unwrap_resp_priv length checks
gss_unwrap_resp_priv() validates the RPCSEC_GSS opaque length with
<pre>
offset = (u8 *)(p) - (u8 *)head->iov_base;
if (offset + opaque_len > rcv_buf->len)
goto unwrap_failed;
maj_stat = gss_unwrap(ctx->gc_gss_ctx, offset,
offset + opaque_len, rcv_buf);
</pre>
Both operands are u32 and the sum is computed in u32. A reply with
opaque_len near 0xffffffff makes offset + opaque_len wrap to a small
value that is below rcv_buf->len, so the bound check passes and
gss_unwrap() is called with end < begin. The check also lacks a
lower bound, so any opaque_len in [0, GSS_KRB5_TOK_HDR_LEN) is
accepted and forwarded to gss_krb5_unwrap_v2(), whose pre-decrypt
header reads at ptr+4 and ptr+6 then run past the token.
A krb5p NFS server returning a crafted RPCSEC_GSS reply can drive
the client into out-of-bounds reads in gss_krb5_unwrap_v2() and the
rotate_left() loop that follows.
Fix by replacing the single combined check with three guards that
are safe in u32 arithmetic and that enforce the RFC 4121 minimum
outer token length:
<pre>
if (offset > rcv_buf->len)
goto unwrap_failed;
if (opaque_len > rcv_buf->len - offset)
goto unwrap_failed;
if (opaque_len < GSS_KRB5_TOK_HDR_LEN)
goto unwrap_failed;
</pre>
The first guard makes the subtraction in the second guard
unconditionally safe; offset is derived from a successful
xdr_inline_decode() in the head kvec, so in practice it already
satisfies the bound. The floor mirrors the server-side check added
in commit 5b757c2e57a5 ("SUNRPC: svcauth_gss: enforce krb5 token
minimum length").
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_unwrap_resp_priv() runs in the Linux NFS/SUNRPC client while decoding RPCSEC_GSS privacy (krb5p) replies; a malicious or compromised NFS server supplies the crafted opaque_len and wrap token over the existing TCP/UDP/RDMA RPC connection.
AC:L - The attacker fully controls the reply, including opaque_len and the cleartext RFC 4121 header, and a single response can make offset+opaque_len wrap in u32 or fall below GSS_KRB5_TOK_HDR_LEN; no race or layout beyond the attacker’s control is required.
PR:N - The attacker is the remote RPC/NFS peer that already holds the GSS session keys needed to pass gss_validate(); no local account, user namespace, or capability on the victim client is required.
UI:N - Once a krb5p NFS mount or other SUNRPC GSS-privacy client is already in use, normal client RPCs elicit replies the attacker can craft; no extra victim action is needed at attack time.
S:U - Out-of-bounds reads, rotate/decrypt memory corruption, and crashes stay inside the victim kernel’s SUNRPC client and do not cross a VM, IOMMU, or other security-authority boundary.
C:H - A short or wrapped opaque_len makes gss_krb5_unwrap_v2() read past the token at ptr+4/ptr+6 and feeds rotate_left()/decrypt with wrapped lengths, disclosing adjacent kernel memory; unwrap cleanup can also memmove nearly UINT_MAX bytes.
I:H - The same wrapped lengths drive rotate_left() writes, CBC/AEAD decrypt over an unbounded xdr subsegment (xdr_buf_subsegment’s error is ignored), and gss_krb5_unwrap_v2()’s unsigned movelen underflow into a near-4GiB memmove, enabling kernel memory corruption.
A:H - rotate_left() can divide-by-zero on a zero-length subbuffer, spin in a multi-gigabyte kernel loop on a wrapped subsegment, or oops/panic on the huge memmove or out-of-bounds header access.
| 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_unwrap_resp_priv() runs in the Linux NFS/SUNRPC client while decoding RPCSEC_GSS privacy (krb5p) replies; a malicious or compromised NFS server supplies the crafted opaque_len and wrap token over the existing TCP/UDP/RDMA RPC connection.
AC:L - The attacker fully controls the reply, including opaque_len and the cleartext RFC 4121 header, and a single response can make offset+opaque_len wrap in u32 or fall below GSS_KRB5_TOK_HDR_LEN; no race or layout beyond the attacker’s control is required.
PR:N - The attacker is the remote RPC/NFS peer that already holds the GSS session keys needed to pass gss_validate(); no local account, user namespace, or capability on the victim client is required.
UI:N - Once a krb5p NFS mount or other SUNRPC GSS-privacy client is already in use, normal client RPCs elicit replies the attacker can craft; no extra victim action is needed at attack time.
S:U - Out-of-bounds reads, rotate/decrypt memory corruption, and crashes stay inside the victim kernel’s SUNRPC client and do not cross a VM, IOMMU, or other security-authority boundary.
C:H - A short or wrapped opaque_len makes gss_krb5_unwrap_v2() read past the token at ptr+4/ptr+6 and feeds rotate_left()/decrypt with wrapped lengths, disclosing adjacent kernel memory; unwrap cleanup can also memmove nearly UINT_MAX bytes.
I:H - The same wrapped lengths drive rotate_left() writes, CBC/AEAD decrypt over an unbounded xdr subsegment (xdr_buf_subsegment’s error is ignored), and gss_krb5_unwrap_v2()’s unsigned movelen underflow into a near-4GiB memmove, enabling kernel memory corruption.
A:H - rotate_left() can divide-by-zero on a zero-length subbuffer, spin in a multi-gigabyte kernel loop on a wrapped subsegment, or oops/panic on the huge memmove or out-of-bounds header access.
CVSS 3.1