Bluetooth: Remove VLA usage in aes_cmac
Subsystems (4)
PATCH 1/1 Bluetooth: Remove VLA usage in aes_cmac
In preparation to enabling -Wvla, remove VLA and replace it with dynamic memory allocation instead.
The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug or a security flaw. Also, in general, as code evolves it is easy to lose track of how big a VLA can get. Thus, we can end up having runtime failures that are hard to debug.
Also, fixed as part of the directive to remove all VLAs from the kernel: https://lkml.org/lkml/2018/3/7/621
--- net/bluetooth/smp.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)
net/bluetooth/smp.c +11 -5
@@ -173,7 +173,7 @@ static int aes_cmac(struct crypto_shash *tfm, const u8 k[16], const u8 *m, size_t len, u8 mac[16]) { uint8_t tmp[16], mac_msb[16], msg_msb[CMAC_MSG_MAX]; -SHASH_DESC_ON_STACK (desc, tfm); +struct shash_desc *shash;int err;if (len >CMAC_MSG_MAX )
@@ -184,8 +184,13 @@ static int aes_cmac(struct crypto_shash *tfm, const u8 k[16], const u8 *m,return -EINVAL ; } - desc->tfm = tfm; - desc->flags =0 ; + shash =kzalloc (sizeof (*shash) +crypto_shash_descsize (tfm), +GFP_KERNEL ); +if (!shash) +return -ENOMEM ; + + shash->tfm = tfm; + shash->flags =0 ;/* Swap key and message from LSB to MSB */ swap_buf (k, tmp,16 );
@@ -200,8 +205,9 @@ static int aes_cmac(struct crypto_shash *tfm, const u8 k[16], const u8 *m,return err; } - err =crypto_shash_digest (desc, msg_msb, len, mac_msb); -shash_desc_zero (desc); + err =crypto_shash_digest (shash, msg_msb, len, mac_msb); +shash_desc_zero (shash); +kfree (shash);if (err) {BT_ERR ("Hash computation error %d" , err);return err;
Signature · 1 line
2.7.4
Hi,
I've just discovered an issue in this patch. Please, drop it. I'll send v2 shortly.
Thanks
--
Gustavo
Quoted 59 lines · Gustavo A. R. Silva
In preparation to enabling -Wvla, remove VLA and replace it with dynamic memory allocation instead.
The use of stack Variable Length Arrays needs to be avoided, as they can be a vector for stack exhaustion, which can be both a runtime bug or a security flaw. Also, in general, as code evolves it is easy to lose track of how big a VLA can get. Thus, we can end up having runtime failures that are hard to debug.
Also, fixed as part of the directive to remove all VLAs from the kernel: https://lkml.org/lkml/2018/3/7/621
Signed-off-by Gustavo A. R. Silva <[email protected]>--- net/bluetooth/smp.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-)net/bluetooth/smp.c +11
-5@@ -173,7 +173,7 @@ static int aes_cmac(struct crypto_shash *tfm, const u8 k[16], const u8 *m, size_t len, u8 mac[16]) { uint8_t tmp[16], mac_msb[16], msg_msb[CMAC_MSG_MAX]; -SHASH_DESC_ON_STACK (desc, tfm); +struct shash_desc *shash;int err;if (len >CMAC_MSG_MAX )@@ -184,8 +184,13 @@ static int aes_cmac(struct crypto_shash *tfm, const u8 k[16], const u8 *m,return -EINVAL ; } - desc->tfm = tfm; - desc->flags =0 ; + shash =kzalloc (sizeof (*shash) +crypto_shash_descsize (tfm), +GFP_KERNEL ); +if (!shash) +return -ENOMEM ; + + shash->tfm = tfm; + shash->flags =0 ;/* Swap key and message from LSB to MSB */ swap_buf (k, tmp,16 );@@ -200,8 +205,9 @@ static int aes_cmac(struct crypto_shash *tfm, const u8 k[16], const u8 *m,return err; } - err =crypto_shash_digest (desc, msg_msb, len, mac_msb); -shash_desc_zero (desc); + err =crypto_shash_digest (shash, msg_msb, len, mac_msb); +shash_desc_zero (shash); +kfree (shash);if (err) {BT_ERR ("Hash computation error %d" , err);return err;