linux-kernel - [PATCH 0/2] fix gss seqno handling to be more rfc-compliant

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20250310A15110284b71e58.njha@janestreet.com>
Date: Mon, 10 Mar 2025 11:11:02 -0400
From: Nikhil Jha <njha@...estreet.com>
To: njha@...estreet.com
Cc: Trond Myklebust <trondmy@...nel.org>, Anna Schumaker <anna@...nel.org>,
 	Chuck Lever <chuck.lever@...cle.com>,
 	Jeff Layton <jlayton@...nel.org>, Neil Brown <neilb@...e.de>,
 	Olga Kornievskaia <okorniev@...hat.com>,
 	Dai Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>,
 	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/2] fix gss seqno handling to be more rfc-compliant

When the client retransmits an operation (for example, because the
server is slow to respond), a new GSS sequence number is associated with
the XID. In the current kernel code the original sequence number is
discarded. Subsequently, if a response to the original request is
received there will be a GSS sequence number mismatch. A mismatch will
trigger another retransmit, possibly repeating the cycle, and after some
number of failed retries EACCES is returned.

RFC2203, section 5.3.3.1 suggests a possible solution... “cache the
RPCSEC_GSS sequence number of each request it sends” and "compute the
checksum of each sequence number in the cache to try to match the
checksum in the reply's verifier." This is what FreeBSD’s implementation
does (rpc_gss_validate in sys/rpc/rpcsec_gss/rpcsec_gss.c).

However, even with this cache, retransmits directly caused by a seqno
mismatch can still cause a bad message interleaving that results in this
bug. The RFC already suggests ignoring incorrect seqnos on the server
side, and this seems symmetric, so this patchset also applies that
behavior to the client as well.

These two patches are *not* dependent on each other. I tested them by
delaying packets with a Python script hooked up to NFQUEUE. If it would
be helpful I can send this script along as well.

Nikhil Jha (2):
  sunrpc: implement rfc2203 rpcsec_gss seqnum cache
  sunrpc: don't retransmit on seqno events

 include/linux/sunrpc/xprt.h    | 31 +++++++++++++++++++++++++++++-
 net/sunrpc/auth_gss/auth_gss.c | 35 +++++++++++++++++++++++-----------
 net/sunrpc/clnt.c              |  9 +++++++--
 net/sunrpc/xprt.c              |  1 +
 4 files changed, 62 insertions(+), 14 deletions(-)

-- 
2.39.3