From patchwork Mon May 25 00:56:27 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Longpeng(Mike)" X-Patchwork-Id: 11567837 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 61E2813B4 for ; Mon, 25 May 2020 00:56:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 543AF20776 for ; Mon, 25 May 2020 00:56:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388309AbgEYA4w (ORCPT ); Sun, 24 May 2020 20:56:52 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:35350 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2388300AbgEYA4t (ORCPT ); Sun, 24 May 2020 20:56:49 -0400 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id B2A869B05EB5BC246CD8; Mon, 25 May 2020 08:56:46 +0800 (CST) Received: from DESKTOP-27KDQMV.china.huawei.com (10.174.151.115) by DGGEMS407-HUB.china.huawei.com (10.3.19.207) with Microsoft SMTP Server id 14.3.487.0; Mon, 25 May 2020 08:56:39 +0800 From: "Longpeng(Mike)" To: CC: "Longpeng(Mike)" , Gonglei , Herbert Xu , "Michael S. Tsirkin" , Jason Wang , "David S. Miller" , , , LABBE Corentin Subject: [PATCH 2/2] crypto: virtio: fix an memory use-after-free bug Date: Mon, 25 May 2020 08:56:27 +0800 Message-ID: <20200525005627.707-3-longpeng2@huawei.com> X-Mailer: git-send-email 2.25.0.windows.1 In-Reply-To: <20200525005627.707-1-longpeng2@huawei.com> References: <20200525005627.707-1-longpeng2@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.174.151.115] X-CFilter-Loop: Reflected Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org The system'll crash when we insmod crypto/tcrypto.ko with mode=155. After dig into this case, I find it's caused by reuse the request memory. In crypto_authenc_init_tfm, we'll set the reqsize to: [PART 1]sizeof(authenc_request_ctx) + [PART 2]ictx->reqoff + [PART 3]MAX(ahash part, skcipher part) and the 'PART 3' will be used by both ahash and skcipher. When virtio_crypto driver finish skcipher req, it'll call ->complete callback(in crypto_finalize_skcipher_request) and then free its resources which pointers are recorded in 'skcipher parts'. However, the ->complete is 'crypto_authenc_encrypt_done' in this case, it will use the 'ahash part' of the request and change its content, so virtio_crypto driver will get the wrong pointer after ->complete finish and mistakenly free some other memory. So the system will crash at last when this memory be used again. We can free the resources before calling ->complete to fix this issue. Cc: Gonglei Cc: Herbert Xu Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: "David S. Miller" Cc: virtualization@lists.linux-foundation.org Cc: linux-kernel@vger.kernel.org Reported-by: LABBE Corentin Signed-off-by: Longpeng(Mike) --- drivers/crypto/virtio/virtio_crypto_algs.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c b/drivers/crypto/virtio/virtio_crypto_algs.c index 2fa1129f96d6..3800356fb764 100644 --- a/drivers/crypto/virtio/virtio_crypto_algs.c +++ b/drivers/crypto/virtio/virtio_crypto_algs.c @@ -587,10 +587,11 @@ static void virtio_crypto_skcipher_finalize_req( scatterwalk_map_and_copy(req->iv, req->dst, req->cryptlen - AES_BLOCK_SIZE, AES_BLOCK_SIZE, 0); - crypto_finalize_skcipher_request(vc_sym_req->base.dataq->engine, - req, err); kzfree(vc_sym_req->iv); virtcrypto_clear_request(&vc_sym_req->base); + + crypto_finalize_skcipher_request(vc_sym_req->base.dataq->engine, + req, err); } static struct virtio_crypto_algo virtio_crypto_algs[] = { {