search for: scatterwalk_map_and_copi

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:

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

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

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

On Mon, 3 Feb 2020 at 20:53, LABBE Corentin <clabbe at baylibre.com> wrote: > > On Thu, Jan 23, 2020 at 06:52:29AM -0500, Michael S. Tsirkin wrote: > > On Thu, Jan 23, 2020 at 11:10:00AM +0100, LABBE Corentin wrote: > > > Hello > > > > > > When modprobing tcrypt on qemu 4.1.0 I get a kernel panic on 5.5-rc7 and next-20200122 > > > qemu is

Since kfree_sensitive() will do an implicit memzero_explicit(), there is no need to call memzero_explicit() before it. Eliminate those memzero_explicit() and simplify the call sites. Signed-off-by: Waiman Long <longman at redhat.com> --- .../crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c | 15 +++------------ .../crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c | 16 +++-------------

Since kfree_sensitive() will do an implicit memzero_explicit(), there is no need to call memzero_explicit() before it. Eliminate those memzero_explicit() and simplify the call sites. For better correctness, the setting of keylen is also moved down after the key pointer check. Signed-off-by: Waiman Long <longman at redhat.com> --- .../allwinner/sun8i-ce/sun8i-ce-cipher.c | 19

Le 14/04/2020 ? 00:28, Waiman Long a ?crit?: > Since kfree_sensitive() will do an implicit memzero_explicit(), there > is no need to call memzero_explicit() before it. Eliminate those > memzero_explicit() and simplify the call sites. For better correctness, > the setting of keylen is also moved down after the key pointer check. > > Signed-off-by: Waiman Long <longman at

Le 14/04/2020 ? 00:28, Waiman Long a ?crit?: > Since kfree_sensitive() will do an implicit memzero_explicit(), there > is no need to call memzero_explicit() before it. Eliminate those > memzero_explicit() and simplify the call sites. For better correctness, > the setting of keylen is also moved down after the key pointer check. > > Signed-off-by: Waiman Long <longman at

This patchset makes a global rename of the kzfree() to kfree_sensitive() to highlight the fact buffer clearing is only needed if the data objects contain sensitive information like encrpytion key. The fact that kzfree() uses memset() to do the clearing isn't totally safe either as compiler may compile out the clearing in their optimizer. Instead, the new kfree_sensitive() uses

As said by Linus: A symmetric naming is only helpful if it implies symmetries in use. Otherwise it's actively misleading. In "kzalloc()", the z is meaningful and an important part of what the caller wants. In "kzfree()", the z is actively detrimental, because maybe in the future we really _might_ want to use that "memfill(0xdeadbeef)" or

As said by Linus: A symmetric naming is only helpful if it implies symmetries in use. Otherwise it's actively misleading. In "kzalloc()", the z is meaningful and an important part of what the caller wants. In "kzfree()", the z is actively detrimental, because maybe in the future we really _might_ want to use that "memfill(0xdeadbeef)" or

v5: - Break the btrfs patch out as a separate patch to be processed independently. - Update the commit log of patch 1 to make it less scary. - Add a kzfree backward compatibility macro in patch 2. v4: - Break out the memzero_explicit() change as suggested by Dan Carpenter so that it can be backported to stable. - Drop the "crypto: Remove unnecessary