similar to: [PATCH 5.4 086/134] crypto: virtio: Fix use-after-free in virtio_crypto_skcipher_finalize_req()

From: Longpeng(Mike) <longpeng2 at huawei.com> [ Upstream commit 8c855f0720ff006d75d0a2512c7f6c4f60ff60ee ] 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) +

From: Longpeng(Mike) <longpeng2 at huawei.com> commit 8c855f0720ff006d75d0a2512c7f6c4f60ff60ee upstream. 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) +

From: Longpeng(Mike) <longpeng2 at huawei.com> commit 8c855f0720ff006d75d0a2512c7f6c4f60ff60ee upstream. 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) +

This is a note to let you know that I've just added the patch titled crypto: virtio: Fix use-after-free in virtio_crypto_skcipher_finalize_req() to the 5.7-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: crypto-virtio-fix-use-after-free-in-virtio_crypto_skcipher_finalize_req.patch

This is a note to let you know that I've just added the patch titled crypto: virtio: Fix use-after-free in virtio_crypto_skcipher_finalize_req() to the 5.6-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is: crypto-virtio-fix-use-after-free-in-virtio_crypto_skcipher_finalize_req.patch

From: Longpeng(Mike) <longpeng2 at huawei.com> [ Upstream commit 8c855f0720ff006d75d0a2512c7f6c4f60ff60ee ] 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) +

> -----Original Message----- > From: Longpeng (Mike, Cloud Infrastructure Service Product Dept.) > Sent: Tuesday, May 26, 2020 11:20 AM > To: linux-crypto at vger.kernel.org > Cc: Longpeng (Mike, Cloud Infrastructure Service Product Dept.) > <longpeng2 at huawei.com>; LABBE Corentin <clabbe at baylibre.com>; Gonglei > (Arei) <arei.gonglei at huawei.com>;

Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface") dated 20 august 2015 introduced the new skcipher API which is supposed to replace both blkcipher and ablkcipher. While all consumers of the API have been converted long ago, some producers of the ablkcipher remain, forcing us to keep the ablkcipher support routines alive, along with the matching code to expose

Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface") dated 20 august 2015 introduced the new skcipher API which is supposed to replace both blkcipher and ablkcipher. While all consumers of the API have been converted long ago, some producers of the ablkcipher remain, forcing us to keep the ablkcipher support routines alive, along with the matching code to expose

From: Longpeng(Mike) <longpeng2 at huawei.com> [ Upstream commit b02989f37fc5e865ceeee9070907e4493b3a21e2 ] The system will crash when the users insmod crypto/tcrypt.ko with mode=38 ( testing "cts(cbc(aes))" ). Usually the next entry of one sg will be @sg@ + 1, but if this sg element is part of a chained scatterlist, it could jump to the start of a new scatterlist array. Fix it

<20200123101000.GB24255 at Red> References: <20200526031956.1897-3-longpeng2 at huawei.com> <20200123101000.GB24255 at Red> Hi [This is an automated email] This commit has been processed because it contains a "Fixes:" tag fixing commit: dbaf0624ffa5 ("crypto: add virtio-crypto driver"). The bot has tested the following trees: v5.6.14, v5.4.42, v4.19.124,

<20200123101000.GB24255 at Red> References: <20200602070501.2023-3-longpeng2 at huawei.com> <20200123101000.GB24255 at Red> Hi [This is an automated email] This commit has been processed because it contains a "Fixes:" tag fixing commit: dbaf0624ffa5 ("crypto: add virtio-crypto driver"). The bot has tested the following trees: v5.6.15, v5.4.43, v4.19.125,

This is a note to let you know that I've just added the patch titled crypto: virtio: Fix src/dst scatterlist calculation in __virtio_crypto_skcipher_do_req() to the 5.7-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

This is a note to let you know that I've just added the patch titled crypto: virtio: Fix src/dst scatterlist calculation in __virtio_crypto_skcipher_do_req() to the 5.6-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

From: Longpeng(Mike) <longpeng2 at huawei.com> [ Upstream commit d90ca42012db2863a9a30b564a2ace6016594bda ] The src/dst length is not aligned with AES_BLOCK_SIZE(which is 16) in some testcases in tcrypto.ko. For example, the src/dst length of one of cts(cbc(aes))'s testcase is 17, the crypto_virtio driver will set @src_data_len=16 but @dst_data_len=17 in this case and get a wrong at

From: Longpeng(Mike) <longpeng2 at huawei.com> [ Upstream commit b02989f37fc5e865ceeee9070907e4493b3a21e2 ] The system will crash when the users insmod crypto/tcrypt.ko with mode=38 ( testing "cts(cbc(aes))" ). Usually the next entry of one sg will be @sg@ + 1, but if this sg element is part of a chained scatterlist, it could jump to the start of a new scatterlist array. Fix it

From: Longpeng(Mike) <longpeng2 at huawei.com> [ Upstream commit b02989f37fc5e865ceeee9070907e4493b3a21e2 ] The system will crash when the users insmod crypto/tcrypt.ko with mode=38 ( testing "cts(cbc(aes))" ). Usually the next entry of one sg will be @sg@ + 1, but if this sg element is part of a chained scatterlist, it could jump to the start of a new scatterlist array. Fix it

This patch convert the driver to the new crypto engine API. Signed-off-by: Corentin Labbe <clabbe.montjoie at gmail.com> --- drivers/crypto/virtio/virtio_crypto_algs.c | 16 ++++++++++------ drivers/crypto/virtio/virtio_crypto_common.h | 3 +-- drivers/crypto/virtio/virtio_crypto_core.c | 3 --- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git

In order to allow for CBC to be chained, which is something that the CTS template relies upon, implementations of CBC need to pass the IV to be used for subsequent invocations via the IV buffer. This was not implemented yet for virtio-crypto so implement it now. Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver") Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc:

In order to allow for CBC to be chained, which is something that the CTS template relies upon, implementations of CBC need to pass the IV to be used for subsequent invocations via the IV buffer. This was not implemented yet for virtio-crypto so implement it now. Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver") Cc: "Michael S. Tsirkin" <mst at redhat.com> Cc: