LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Eric Biggers <ebiggers@google.com>
To: Michael Young <m.a.young@durham.ac.uk>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Jeff Layton <jlayton@kernel.org>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	Anna Schumaker <anna.schumaker@netapp.com>,
	linux-nfs@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: NFS mounts failing when keytab present on client
Date: Tue, 27 Mar 2018 15:29:50 -0700
Message-ID: <20180327222950.GB257332@google.com> (raw)
In-Reply-To: <alpine.LFD.2.21.1803272126070.3013@austen3.home>

Hi Michael,

On Tue, Mar 27, 2018 at 11:06:14PM +0100, Michael Young wrote:
> NFS mounts stopped working on one of my computers after a kernel update from
> 4.15.3 to 4.15.4. I traced the problem to the commit
> [46e8d06e423c4f35eac7a8b677b713b3ec9b0684] crypto: hash - prevent using
> keyed hashes without setting key
> and a later kernel with this patch reverted works normally.
> 
> The problem seems to be related to kerberos as the mount fails when the
> keytab is present, but works if I rename the keytab file. This is true even
> though the mount is with sec=sys . The mount should also work with sec=krb5
> but that also fails in the same way. When the mount fails there are errors
> in dmesg like
> [ 1232.522816] gss_marshal: gss_get_mic FAILED (851968)
> [ 1232.522819] RPC: couldn't encode RPC header, exit EIO
> [ 1232.522856] gss_marshal: gss_get_mic FAILED (851968)
> [ 1232.522857] RPC: couldn't encode RPC header, exit EIO
> [ 1232.522863] NFS: nfs4_discover_server_trunking unhandled error -5.
> Exiting with error EIO
> [ 1232.525039] gss_marshal: gss_get_mic FAILED (851968)
> [ 1232.525042] RPC: couldn't encode RPC header, exit EIO
> 
> 	Michael Young

Thanks for the bug report.  I think the error is coming from
net/sunrpc/auth_gss/gss_krb5_crypto.c.  There are two potential problems I see.
The first one, which is definitely a bug, is that make_checksum_hmac_md5()
allocates an HMAC transform and request, then does these crypto API calls:

	crypto_ahash_init()
	crypto_ahash_setkey()
	crypto_ahash_digest()

This is wrong because it makes no sense to init() the HMAC request before the
key has been set, and doubly so when it's calling digest() which is shorthand
for init() + update() + final().  So I think it just needs to be removed.  You
can test the following patch:

diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c b/net/sunrpc/auth_gss/gss_krb5_crypto.c
index 12649c9fedab..8654494b4d0a 100644
--- a/net/sunrpc/auth_gss/gss_krb5_crypto.c
+++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c
@@ -237,9 +237,6 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
 
        ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
 
-       err = crypto_ahash_init(req);
-       if (err)
-               goto out;
        err = crypto_ahash_setkey(hmac_md5, cksumkey, kctx->gk5e->keylength);
        if (err)
                goto out;

If that's not it, it's also possible that the error is coming from the
crypto_ahash_init() in make_checksum().  That can only happen if 'cksumkey' is
NULL and the hash algorithm is keyed, which implies a logical error as it
doesn't make sense to use a keyed hash algorithm without the key.  The callers
do check kctx->gk5e->keyed_cksum which I'd hope would prevent this, though
perhaps kctx->cksum can be NULL.

Eric

  reply index

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-27 22:06 Michael Young
2018-03-27 22:29 ` Eric Biggers [this message]
2018-03-28  8:00   ` M A Young
2018-03-28 17:47     ` Eric Biggers
2018-03-28 15:46   ` J. Bruce Fields
2018-03-28 17:50     ` Eric Biggers
2018-03-28 18:03       ` J. Bruce Fields
2018-03-28 18:04         ` J. Bruce Fields

Reply instructions:

You may reply publically 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=20180327222950.GB257332@google.com \
    --to=ebiggers@google.com \
    --cc=anna.schumaker@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jlayton@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=m.a.young@durham.ac.uk \
    --cc=netdev@vger.kernel.org \
    --cc=trond.myklebust@primarydata.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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org linux-kernel@archiver.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox