From: Chuck Lever <cel@kernel.org>
To: Trond Myklebust <trond.myklebust@hammerspace.com>,
Anna Schumaker <anna@kernel.org>, NeilBrown <neil@brown.name>,
Jeff Layton <jlayton@kernel.org>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <dai.ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: <linux-nfs@vger.kernel.org>, Chuck Lever <chuck.lever@oracle.com>
Subject: [PATCH 0/4] sunrpc: close length validation gaps in krb5p unwrap
Date: Sat, 23 May 2026 21:02:09 -0400 [thread overview]
Message-ID: <20260524010213.557424-1-cel@kernel.org> (raw)
From: Chuck Lever <chuck.lever@oracle.com>
Neither svcauth_gss_unwrap_priv() nor gss_unwrap_resp_priv()
enforces a minimum on the wire-supplied opaque length before
forwarding it to the krb5 unwrap core. An authenticated krb5p
peer -- NFS client or server -- can send a token shorter than the
16-byte RFC 4121 header and reach gss_krb5_unwrap_v2() with a
length that drives pre-decrypt out-of-bounds reads, a
divide-by-zero in _rotate_left(), and a post-decrypt unsigned
underflow in the movelen computation that feeds a multi-gigabyte
memmove.
The fixes are layered so that neither the caller boundary nor
the unwrap core depends on the other for safety. The caller-side
floor checks (patches 1, 2) are sufficient to close the attack,
but gss_krb5_unwrap_v2() must also be self-defending because it
is reachable through gss_unwrap() from any future caller that
might not enforce the same floor. The xdr_buf_trim() clamp
(patch 3) is independent of krb5 -- it corrects a generic
invariant violation that gss_krb5_unwrap_v2() happens to be the
only current trigger for, but that any caller could hit if
buf->len and the component iov_lens get out of sync.
The client side (patch 2) has an additional u32 integer-overflow
bypass that the server side does not: the original
`offset + opaque_len > rcv_buf->len` wraps when opaque_len is
near UINT_MAX, accepting a huge token length that re-enters the
same underflow chain. The replacement splits the check into
separate offset and length guards that are safe in u32 arithmetic.
Chris Mason (4):
SUNRPC: svcauth_gss: enforce krb5 token minimum length
SUNRPC: harden gss_unwrap_resp_priv length checks
SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow
SUNRPC: harden gss_krb5_unwrap_v2 against short tokens
net/sunrpc/auth_gss/auth_gss.c | 6 +++++-
net/sunrpc/auth_gss/gss_krb5_wrap.c | 11 +++++++++--
net/sunrpc/auth_gss/svcauth_gss.c | 2 ++
net/sunrpc/xdr.c | 2 +-
4 files changed, 17 insertions(+), 4 deletions(-)
--
2.54.0
next reply other threads:[~2026-05-24 1:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-24 1:02 Chuck Lever [this message]
2026-05-24 1:02 ` [PATCH 1/4] SUNRPC: svcauth_gss: enforce krb5 token minimum length Chuck Lever
2026-05-24 1:02 ` [PATCH 2/4] SUNRPC: harden gss_unwrap_resp_priv length checks Chuck Lever
2026-05-24 1:02 ` [PATCH 3/4] SUNRPC: xdr_buf_trim: clamp buf->len to avoid underflow Chuck Lever
2026-05-24 1:02 ` [PATCH 4/4] SUNRPC: harden gss_krb5_unwrap_v2 against short tokens Chuck Lever
2026-05-24 10:56 ` [PATCH 0/4] sunrpc: close length validation gaps in krb5p unwrap Jeff Layton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260524010213.557424-1-cel@kernel.org \
--to=cel@kernel.org \
--cc=anna@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
--cc=trond.myklebust@hammerspace.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.