Brian Norris writes:
> Hi,
>
> On Tue, Aug 25, 2020 at 8:38 AM Maximilian Luz
> 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 repe
On 8/25/20 9:30 PM, Brian Norris wrote:
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
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 (a
Hi,
On Tue, Aug 25, 2020 at 8:38 AM Maximilian Luz 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
On Tue, Aug 25, 2020 at 05:38:29PM +0200, Maximilian Luz 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. T
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):
6 matches
Mail list logo