lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 25 Aug 2020 22:17:10 +0200 From: Maximilian Luz <luzmaximilian@...il.com> To: Dan Carpenter <dan.carpenter@...cle.com> Cc: Amitkumar Karwar <amitkarwar@...il.com>, Ganapathi Bhat <ganapathi.bhat@....com>, Xinming Hu <huxinming820@...il.com>, Kalle Valo <kvalo@...eaurora.org>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, linux-wireless@...r.kernel.org, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Kaloyan Nikolov <konik98@...il.com>, Brian Norris <briannorris@...omium.org> Subject: Re: [PATCH net] mwifiex: Increase AES key storage size to 256 bits On 8/25/20 8:51 PM, Dan Carpenter wrote: > I sort of feel like the code was broken before I added the bounds > checking but it's also okay if the Fixes tag points to my change as > well just to make backporting easier. I'd argue the same. Any critical out-of-bounds access was just never discovered (at least for 256 bit keys) due to the struct containing the key being a union member, as Brian observed. > Another question would be if it would be better to move the bounds > check after the "if (key_v2->key_param_set.key_type != KEY_TYPE_ID_AES)" > check? Do we care if the length is invalid on the other paths? Given that I have pretty much no knowledge of the driver, I unfortunately can't answer this. But I agree that this should be looked at. I think this has the potential to work now (as long as the maximum key size is 256 bit) but break in the future if the maximum key size ever gets larger and the check excludes some key types that would be valid in this context (if there are even any?). Regards, Max
Powered by blists - more mailing lists