Re: Kernel panic - encryption/decryption failed when open file on Arm64

From: xiakaixu
Date: Fri Sep 09 2016 - 00:09:54 EST

Sorry for resend this email, just add the linux-crypto@xxxxxxxxxxxxxxx
and linux-kernel@xxxxxxxxxxxxxxxx


Firstly, thanks for your reply!

To reproduce this kernel panic, I test the encryption/decryption feature on arm64 board with more memory. Just add the following

diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
index 0122bec..10ef3f4 100644
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -240,6 +240,7 @@ static int blkcipher_walk_next(struct blkcipher_desc *desc,
walk->flags |= BLKCIPHER_WALK_COPY;
if (!walk->page) {
walk->page = (void *)__get_free_page(GFP_ATOMIC);
+ walk->page = NULL;
if (!walk->page)
n = 0;

This change just set the walk->page to NULL manually.
I get the same crash when open file with the above change log. So I think this NULL page failure is not be handled correctly in current code.

Kaixu Xia

On Thu, Sep 08, 2016 at 08:38:43PM +0800, xiakaixu wrote:

I am using the encryption/decryption feature on arm64 board and a kernel
panic occurs just when open a file. As the memory size of the board
is limited
and there are some page allocation failures before the panic.

Seems it is a kernel bug from the call trace log.

- fscrypt_get_encryption_info
- get_crypt_info.part.1
- validate_user_key.isra.0
- derive_aes_gcm_key
- crypto_gcm_decrypt
- ablk_decrypt
- ctr_encrypt
- blkcipher_walk_done
- blkcipher_walk_next
- __get_free_pages
----------------------------------> page allocation failure
- aes_ctr_encrypt
-----------------------------------------> the input parameter is
NULL pointer as the page allocation failure

The input parameter of function aes_ctr_encrypt() comes from the
/struct blkcipher_walk//
//walk/, and this variable /walk /is allocated by the function
__get_free_pages(). So if this
page allocate failed, the input parameter of function
aes_ctr_encrypt() will be NULL. The
panic will occurs if we don't check the input parameter.

Not sure about this and wish to get your opinions!

If the page allocation fails in blkcipher_walk_next it'll simply
switch over to processing it block by block. so I don't think the
warning is related to the crash.