WTF: patch "[PATCH] fscrypto: don't use on-stack buffer for key derivation" was seriously submitted to be applied to the 4.8-stable tree?
Subsystems (2)
[email protected]
maintainerThe patch below was submitted to be applied to the 4.8-stable tree.
I fail to see how this patch meets the stable kernel rules as found at Documentation/stable_kernel_rules.txt.
I could be totally wrong, and if so, please respond to <[email protected]> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
Quoted 1 line
From
0f0909e242f73c1154272cf04f07fc9afe13e5b8Mon Sep 17 00:00:00 2001
From: Eric Biggers <[email protected]>
Date: Sun, 13 Nov 2016 20:41:09 -0500
Subject: [PATCH] fscrypto: don't use on-stack buffer for key derivation
With the new (in 4.9) option to use a virtually-mapped stack (CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for the scatterlist crypto API because they may not be directly mappable to struct page. get_crypt_info() was using a stack buffer to hold the output from the encryption operation used to derive the per-file key. Fix it by using a heap buffer.
This bug could most easily be observed in a CONFIG_DEBUG_SG kernel because this allowed the BUG in sg_set_buf() to be triggered.
fs/crypto/keyinfo.c +13 -3
@@ -185,7 +185,7 @@ int get_crypt_info(struct inode *inode)struct crypto_skcipher *ctfm;const char *cipher_str;int keysize; -u8 raw_key[FS_MAX_KEY_SIZE ]; +u8 *raw_key =NULL ;int res; res =fscrypt_initialize ();
@@ -238,6 +238,15 @@ int get_crypt_info(struct inode *inode)if (res) goto out; +/* +* This cannot be a stack buffer because it is passed to the scatterlist +* crypto API as part of key derivation. +*/ + res = -ENOMEM ; + raw_key =kmalloc (FS_MAX_KEY_SIZE ,GFP_NOFS ); +if (!raw_key) + goto out; +if (fscrypt_dummy_context_enabled (inode)) {memset (raw_key,0x42 ,FS_AES_256_XTS_KEY_SIZE ); goto got_key;
@@ -276,7 +285,8 @@ int get_crypt_info(struct inode *inode)if (res) goto out; -memzero_explicit (raw_key,sizeof (raw_key)); +kzfree (raw_key); + raw_key =NULL ;if (cmpxchg (&inode->i_crypt_info,NULL , crypt_info) !=NULL ) {put_crypt_info (crypt_info); goto retry;
@@ -287,7 +297,7 @@ int get_crypt_info(struct inode *inode)if (res == -ENOKEY ) res =0 ;put_crypt_info (crypt_info); -memzero_explicit (raw_key,sizeof (raw_key)); +kzfree (raw_key);return res; }
Quoted 5 lines · On Mon, Nov 21, 2016 at 01:39:02PM +0100, [email protected] wrote:
The patch below was submitted to be applied to the 4.8-stable tree.
I fail to see how this patch meets the stable kernel rules as found at
Documentation/stable_kernel_rules.txt.
Quoted 9 lines
I could be totally wrong, and if so, please respond to <[email protected]> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.
thanks,
greg k-h
Hi Greg,
Indeed, as far as I'm concerned you should drop these two patches. They fix problems with virtually-mapped stacks which were added in 4.9, so there's no need to apply them to older kernels. I think Cc stable was left on by accident because the patches were originally going to wait until 4.10.
Thanks!
Eric
Greg KH
maintainerQuoted 16 lines · Eric Biggers
Quoted 5 lines · On Mon, Nov 21, 2016 at 01:39:02PM +0100, [email protected] wrote:
The patch below was submitted to be applied to the 4.8-stable tree.
I fail to see how this patch meets the stable kernel rules as found at
Documentation/stable_kernel_rules.txt.Quoted 9 lines
I could be totally wrong, and if so, please respond to <[email protected]> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.
thanks,
greg k-h
Quoted 6 lines
Hi Greg,
Indeed, as far as I'm concerned you should drop these two patches. They fix problems with virtually-mapped stacks which were added in 4.9, so there's no need to apply them to older kernels. I think Cc stable was left on by accident because the patches were originally going to wait until 4.10.
Ok, thanks, both now dropped.
greg k-h