Received: by 10.192.165.156 with SMTP id m28csp1107251imm; Wed, 11 Apr 2018 12:32:59 -0700 (PDT) X-Google-Smtp-Source: AIpwx49zQoS/Ao7uSkMEzVBDmm9Xq8ymJ97GCs65EKOUKXwxschlANNUt1bijaJjZx8OOdKm9acN X-Received: by 10.98.133.212 with SMTP id m81mr5119918pfk.61.1523475179487; Wed, 11 Apr 2018 12:32:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523475179; cv=none; d=google.com; s=arc-20160816; b=RbH+yvoFBJgXCjHjkGkg0cdtGKfNm6Fw5hwuycEjcy9Zw5+0yL3b04cj0ngUYxmn/q 9LplIMdTS6MYjQbHcaHOm7DZxgpqrO/lf8RGFUHFPdNhsKual5lZayhkjC7yRtEyzTHW LrAM3QfEUYbBcfDT13iKUXmd9k7MLBlfbMupzYumshbN4aa5GE0np0JFsBQrNEFdIZMK WQ2dQMKVFb//7q6GfUOni+ZJCEY3FHewQLlXSTlKmMhwWIMkVRF4blNdG701AncnU0Xf O/jlwn1g0l5vBQrEbhmNlIBfPoRBRSumD+wyoS1O88HPbUkmj1o5dXIq29mv7Y8oVQf6 c7Mw== 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=QPOvpls5cnOjvzt/HdfCu9agdJ+yExXeq5LVRsnhqYE=; b=BjkIqzRP41770CXphnNeOsgkK1nhKVmZ2ZxDzqb5W8QC8ndKk05wrSBa5zn7KpTrIb ECOX8ZxzjRNAXLFMBu2lscj+8CqvBScJucg41Bk1z6wBjDrDiTlqNkWM/gBsjpuD/lKn jzosKSgMDhfa2RMtjtXzRA0mK+yKl6fxcaRDD4qWjkRe/Tm5EUlNZJgNp/hjppJXz/S4 24GW/Cm5CtBS0sgpdsXzs7dY8yzaqffDUmjea9uzob4ig1ZLKbX8WXRGbYkuOKOWqTXv sCxbW3KdgEKgcmtOyigmiRMSPquwrFHKjFmHN3KQ9z8Y+Ahf1L07sZVtvmlrQAU1IX6B ebMQ== 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 p12-v6si1696348plo.55.2018.04.11.12.32.23; Wed, 11 Apr 2018 12:32:59 -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 S1756970AbeDKT0i (ORCPT + 99 others); Wed, 11 Apr 2018 15:26:38 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:38930 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934655AbeDKTDY (ORCPT ); Wed, 11 Apr 2018 15:03:24 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 43B40E42; Wed, 11 Apr 2018 19:03:23 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tero Kristo , Aparna Balasubramanian , Herbert Xu , Sasha Levin Subject: [PATCH 4.9 235/310] crypto: omap-sham - fix closing of hash with separate finalize call Date: Wed, 11 Apr 2018 20:36:14 +0200 Message-Id: <20180411183632.611968069@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180411183622.305902791@linuxfoundation.org> References: <20180411183622.305902791@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.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tero Kristo [ Upstream commit 898d86a565925f09de3d0b30cf3b47ec2e409680 ] Currently there is an interesting corner case failure with omap-sham driver, if the finalize call is done separately with no data, but all previous data has already been processed. In this case, it is not possible to close the hash with the hardware without providing any data, so we get incorrect results. Fix this by adjusting the size of data sent to the hardware crypto engine in case the non-final data size falls on the block size boundary, by reducing the amount of data sent by one full block. This makes it sure that we always have some data available for the finalize call and we can close the hash properly. Signed-off-by: Tero Kristo Reported-by: Aparna Balasubramanian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/crypto/omap-sham.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/drivers/crypto/omap-sham.c +++ b/drivers/crypto/omap-sham.c @@ -750,7 +750,10 @@ static int omap_sham_align_sgs(struct sc if (final) new_len = DIV_ROUND_UP(new_len, bs) * bs; else - new_len = new_len / bs * bs; + new_len = (new_len - 1) / bs * bs; + + if (nbytes != new_len) + list_ok = false; while (nbytes > 0 && sg_tmp) { n++; @@ -846,6 +849,8 @@ static int omap_sham_prepare_request(str xmit_len = DIV_ROUND_UP(xmit_len, bs) * bs; else xmit_len = xmit_len / bs * bs; + } else if (!final) { + xmit_len -= bs; } hash_later = rctx->total - xmit_len; @@ -1137,7 +1142,7 @@ retry: ctx = ahash_request_ctx(req); err = omap_sham_prepare_request(req, ctx->op == OP_UPDATE); - if (err) + if (err || !ctx->total) goto err1; dev_dbg(dd->dev, "handling new req, op: %lu, nbytes: %d\n",