similar to: Patch "crypto: virtio: Fix src/dst scatterlist calculation in __virtio_crypto_skcipher_do_req()" has been added to the 5.6-stable tree

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:

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

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

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

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

On 2020/5/25 ??8:56, Longpeng(Mike) wrote: > The system will crash when we insmod crypto/tcrypt.ko whit mode=38. > > 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. Let's fix it by sg_next() on calculation of src/dst > scatterlist. > > BTW I add a check

This is a note to let you know that I've just added the patch titled crypto: virtio: Fix dest length 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:

This is a note to let you know that I've just added the patch titled crypto: virtio: Fix dest length 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:

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

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> commit d90ca42012db2863a9a30b564a2ace6016594bda upstream. 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 then

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 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 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 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

Hi Herbert, Would you please review and/or ack the virtio_crypto_algs.c? It is the realization of specified algs based on Linux Crypto Framework. Thanks! Regards, -Gonglei > -----Original Message----- > From: Gonglei (Arei) > Sent: Thursday, December 01, 2016 8:39 PM > To: linux-kernel at vger.kernel.org; qemu-devel at nongnu.org; > virtio-dev at lists.oasis-open.org;

Hi Herbert, Would you please review and/or ack the virtio_crypto_algs.c? It is the realization of specified algs based on Linux Crypto Framework. Thanks! Regards, -Gonglei > -----Original Message----- > From: Gonglei (Arei) > Sent: Thursday, December 01, 2016 8:39 PM > To: linux-kernel at vger.kernel.org; qemu-devel at nongnu.org; > virtio-dev at lists.oasis-open.org;

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