Received: by 2002:a25:2c96:0:0:0:0:0 with SMTP id s144csp1556829ybs; Mon, 25 May 2020 20:21:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwM14LVY75eH7nWpv0xJJEQm6ozyL3UfACekor2Ya0p3Y+CpoMT8rZetoW1+sHF6lIMOK/T X-Received: by 2002:a17:906:1ed3:: with SMTP id m19mr22071389ejj.429.1590463261153; Mon, 25 May 2020 20:21:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590463261; cv=none; d=google.com; s=arc-20160816; b=Wd0glvpJzpTOmyWTBIhug8+LUF24X+IO9DxbcAAQDL6oc1pXHZMINh0yB5i1YTws9+ et4RUFXd+Zqxs7/lMkGC/hvKwPe62ilm2dh8wVXzGvhX2BDOdTlXhzMqMdQov7I4g/z/ QjkEdsEm4GGqtvO852cYQOotdDna1IsozCoIMKPyrCkaDcFcGhhwjk08+ZRFOQp0MwJC twj+oG40+ezMuVoz5h5gaCirDuQ30hC63C53MyejEtovxTwycDF2SWjUS+91QEl4tWZa bubgSL6pd0GvIVQGe4fWo7Vg48DNOXkv4XrFZ9XYU2GRKvNuV4R2yUGwR4hSuhE6mRW2 11gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=SbZtOa1A2zP2tx99cd4vHfuVniK/qtwTF6OOvDmBBjU=; b=0Lr6Ju56hwKpPHomy0ROfJ43FE3tCTdrF2/pVqVG0bLgZJtXoP0AfwMHlhoVUE2k/S Xb95DwS8tm6He7/JFQr2fIi8ncB87jcmP5rLmCtGJHOpOsapXP9pZZWtvX8UFCgmOrXS SHQyjPX3nJuYRuQhlbZtxTUZ1nuWahNx/IDxgGKAODLv+crZyCr5pJ3l3YTLLSJNirVA Dgfz+eMH22bpGH8klZR2cO3sgWWpaVLFSWzCTlFd4+KnKwPqNRPMhwn3H7X01QEsORco b8tnySBUNUrBf3BSCm8mjFJ3praSg5dNrLvq9iO5gzz7Ki/42dbWygmGcoCZoHZJKaml XKsw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ca1si9999705ejb.42.2020.05.25.20.20.38; Mon, 25 May 2020 20:21:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388559AbgEZDU1 (ORCPT + 99 others); Mon, 25 May 2020 23:20:27 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:40998 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725535AbgEZDU0 (ORCPT ); Mon, 25 May 2020 23:20:26 -0400 Received: from DGGEMS407-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 66F7F47E735B39230401; Tue, 26 May 2020 11:20:24 +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; Tue, 26 May 2020 11:20:17 +0800 From: "Longpeng(Mike)" To: CC: "Longpeng(Mike)" , LABBE Corentin , Gonglei , Herbert Xu , "Michael S. Tsirkin" , "Jason Wang" , "David S. Miller" , "Markus Elfring" , , , Subject: [PATCH v2 2/2] crypto: virtio: Fix use-after-free in virtio_crypto_skcipher_finalize_req() Date: Tue, 26 May 2020 11:19:56 +0800 Message-ID: <20200526031956.1897-3-longpeng2@huawei.com> X-Mailer: git-send-email 2.25.0.windows.1 In-Reply-To: <20200526031956.1897-1-longpeng2@huawei.com> References: <20200526031956.1897-1-longpeng2@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII 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 the users insmod crypto/tcrypto.ko with mode=155 ( testing "authenc(hmac(sha1),cbc(aes))" ). It's caused by reuse the memory of request structure. In crypto_authenc_init_tfm(), the reqsize is set to: [PART 1] sizeof(authenc_request_ctx) + [PART 2] ictx->reqoff + [PART 3] MAX(ahash part, skcipher part) and the 'PART 3' is used by both ahash and skcipher in turn. When the virtio_crypto driver finish skcipher req, it'll call ->complete callback(in crypto_finalize_skcipher_request) and then free its resources whose 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's memory. So the system will crash when these memory will be used again. The resources which need to be cleaned up are not used any more. But the pointers of these resources may be changed in the function "crypto_finalize_skcipher_request". Thus release specific resources before calling this function. Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver") Reported-by: LABBE Corentin Cc: Gonglei Cc: Herbert Xu Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: "David S. Miller" Cc: Markus Elfring Cc: virtualization@lists.linux-foundation.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Message-Id: <20200123101000.GB24255@Red> 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 5f8243563009..52261b6c247e 100644 --- a/drivers/crypto/virtio/virtio_crypto_algs.c +++ b/drivers/crypto/virtio/virtio_crypto_algs.c @@ -582,10 +582,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[] = { { -- 2.23.0