Received: by 10.192.165.156 with SMTP id m28csp271795imm; Tue, 17 Apr 2018 09:54:02 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+Oh38Ce/ZQCehNEffyrhDLJsuXbfITmNNf6HA31Kn/ymXJdRFg7luR1qsnVrKMjzIYpEO8 X-Received: by 2002:a17:902:2c83:: with SMTP id n3-v6mr2772206plb.317.1523984042139; Tue, 17 Apr 2018 09:54:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523984042; cv=none; d=google.com; s=arc-20160816; b=llpx7LKTY/lturb4HiAKdVTPc9NdHjjUR2o2saRAWpT/wEJzhR7Z8xAV5duFUImYU3 Hn62af5FBw1DGdBISB521VggWy4dJNYR5w+BhIRYlxQh6KKdVAA/m6qYzqUMyNsGtqFU so8za4jJ50soTTT2Va5Yrn+1Zz9P+vC46+FAr48D59/KVe7EcfJs69+JuA/Ewmzv94se 9gRlFf2qNtCOaVhqts+c/m1cSNk9CN3LFVpllp6amJ8ppnipBrXXN8unCTPYHO+Zj+Le 92uaoLUuB6xQXlDU1+L8Phov1FrdwecpmOYl7eERlizRqVDJaM2rU7CRetCe1jd62rQk UMDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=adKGoFck9Z+keFp9sQRu2udg7nzo0SPR69P5SRINkP0=; b=YGJPwm+UnPyyo7iXyG416tOEzMNcwkJZeY7F5mMyPyIyB/P59Ha5EUhjBtomMKKJLq ElR7RoIGHLM47AiYUvdS8LXzci/bIrk4D07AJafW03qGPOae/3AGWERcCTKPSmRb8OoH euDdHq8pAIFxHgPqTYULZZDmkCNiu5fhIHgfpKpMZbCXw1TNhmjsHmgjAGjYQd3pynwG CZpf/IQvti1nvAlFMTL8KjWe3NhX+VfEonNWv9TwLHV3wBBP9mX5Njm0PosGfU79Vxxa zRGOMbecdZzp0mxNhH14hPp4en1n3HInsRaK5jilwz2dqnFvGAAAYiTHYhLP30GUhGNg ECZA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si14556271plj.247.2018.04.17.09.53.48; Tue, 17 Apr 2018 09:54:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754614AbeDQQwr (ORCPT + 99 others); Tue, 17 Apr 2018 12:52:47 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:33158 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754441AbeDQQEB (ORCPT ); Tue, 17 Apr 2018 12:04:01 -0400 Received: from localhost (unknown [46.44.180.42]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 976B1F45; Tue, 17 Apr 2018 16:04:00 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Michael Young , Eric Biggers , "J. Bruce Fields" Subject: [PATCH 4.15 26/53] sunrpc: remove incorrect HMAC request initialization Date: Tue, 17 Apr 2018 17:58:51 +0200 Message-Id: <20180417155724.416498922@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180417155723.091120060@linuxfoundation.org> References: <20180417155723.091120060@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Eric Biggers commit f3aefb6a7066e24bfea7fcf1b07907576de69d63 upstream. make_checksum_hmac_md5() is allocating an HMAC transform and doing crypto API calls in the following order: crypto_ahash_init() crypto_ahash_setkey() crypto_ahash_digest() This is wrong because it makes no sense to init() the request before a key has been set, given that the initial state depends on the key. And digest() is short for init() + update() + final(), so in this case there's no need to explicitly call init() at all. Before commit 9fa68f620041 ("crypto: hash - prevent using keyed hashes without setting key") the extra init() had no real effect, at least for the software HMAC implementation. (There are also hardware drivers that implement HMAC-MD5, and it's not immediately obvious how gracefully they handle init() before setkey().) But now the crypto API detects this incorrect initialization and returns -ENOKEY. This is breaking NFS mounts in some cases. Fix it by removing the incorrect call to crypto_ahash_init(). Reported-by: Michael Young Fixes: 9fa68f620041 ("crypto: hash - prevent using keyed hashes without setting key") Fixes: fffdaef2eb4a ("gss_krb5: Add support for rc4-hmac encryption") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman --- net/sunrpc/auth_gss/gss_krb5_crypto.c | 3 --- 1 file changed, 3 deletions(-) --- 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 * 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;