[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+ASDXPoxdMb4b5d0Ayv=JFACHcq7EXub14pJtJfcCV2di95Rg@mail.gmail.com>
Date: Tue, 25 Aug 2020 12:30:28 -0700
From: Brian Norris <briannorris@...omium.org>
To: Maximilian Luz <luzmaximilian@...il.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>,
Dan Carpenter <dan.carpenter@...cle.com>,
linux-wireless <linux-wireless@...r.kernel.org>,
"<netdev@...r.kernel.org>" <netdev@...r.kernel.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Kaloyan Nikolov <konik98@...il.com>
Subject: Re: [PATCH net] mwifiex: Increase AES key storage size to 256 bits
Hi,
On Tue, Aug 25, 2020 at 8:38 AM Maximilian Luz <luzmaximilian@...il.com> wrote:
>
> Following commit e18696786548 ("mwifiex: Prevent memory corruption
> handling keys") the mwifiex driver fails to authenticate with certain
> networks, specifically networks with 256 bit keys, and repeatedly asks
> for the password. The kernel log repeats the following lines (id and
> bssid redacted):
>
> mwifiex_pcie 0000:01:00.0: info: trying to associate to '<id>' bssid <bssid>
> mwifiex_pcie 0000:01:00.0: info: associated to bssid <bssid> successfully
> mwifiex_pcie 0000:01:00.0: crypto keys added
> mwifiex_pcie 0000:01:00.0: info: successfully disconnected from <bssid>: reason code 3
>
> Tracking down this problem lead to the overflow check introduced by the
> aforementioned commit into mwifiex_ret_802_11_key_material_v2(). This
> check fails on networks with 256 bit keys due to the current storage
> size for AES keys in struct mwifiex_aes_param being only 128 bit.
>
> To fix this issue, increase the storage size for AES keys to 256 bit.
>
> Signed-off-by: Maximilian Luz <luzmaximilian@...il.com>
> Reported-by: Kaloyan Nikolov <konik98@...il.com>
> Tested-by: Kaloyan Nikolov <konik98@...il.com>
Thanks for this! I just happened to notice this breakage here, as we
just merged the relevant -stable updates. I think it would be wise to
get the Fixes tag Dan noted, when Kalle lands this.
Reviewed-by: Brian Norris <briannorris@...omium.org>
Tested-by: Brian Norris <briannorris@...omium.org>
Also, while technically the regressing commit (e18696786548 ("mwifiex:
Prevent memory corruption handling keys")) was fixing a potential
overflow, the encasing command structure (struct host_cmd_ds_command)
is a union of a ton of other command layouts, and likely had plenty of
padding at the end, which would at least explain why non-malicious
scenarios weren't problematic pre-commit-e18696786548. It's also not
clear to me how much the network can directly determine this length,
but I suppose that's beside the point now -- it's good to fix both of
these bugs.
Regards,
Brian
Powered by blists - more mailing lists