linux-kernel - Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <37ba6cb0-d887-4fcf-b7dc-c93a5fc5900f@gmail.com>
Date: Mon, 17 Jun 2024 08:40:23 -0700
From: James Prestwood <prestwoj@...il.com>
To: Kalle Valo <kvalo@...nel.org>
Cc: Paul Menzel <pmenzel@...gen.mpg.de>, linux-wireless@...r.kernel.org,
 ath10k@...ts.infradead.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: invalid vht params rate 1920 100kbps nss 2 mcs 9

Hi Kalle,

On 6/17/24 8:27 AM, Kalle Valo wrote:
> James Prestwood <prestwoj@...il.com> writes:
>
>> Hi Paul,
>>
>> On 6/16/24 6:10 AM, Paul Menzel wrote:
>>> Dear Linux folks,
>>>
>>>
>>> Linux 6.10-rc3 (commit a3e18a540541) logged the warning below when
>>> connecting to a public WiFi:
>>>
>>>      ath10k_pci 0000:3a:00.0: invalid vht params rate 1920 100kbps
>>> nss 2 mcs 9
>> This has been reported/discussed [1]. It was hinted that there was a
>> firmware fix for this, but none that I tried got rid of it. I got fed
>> up enough with the logs filling up with this I patched our kernel to
>> remove the warning. AFAICT it appears benign (?). Removing the warning
>> was purely "cosmetic" so other devs stopped complaining about it :)
>>
>> [1] https://www.mail-archive.com/ath10k@lists.infradead.org/msg13406.html
> More reliable link to the discussion:
>
> https://lore.kernel.org/ath10k/76a816d983e6c4d636311738396f97971b5523fb.1612915444.git.skhan@linuxfoundation.org/
>
> I think we should add this workaround I mentioned in 2021:
>
>     "If the firmware still keeps sending invalid rates we should add a
>      specific check to ignore the known invalid values, but not all of
>      them."
>
>     https://lore.kernel.org/ath10k/87h7mktjgi.fsf@codeaurora.org/
>
> I guess that would be mcs == 7 and rate == 1440?
I think its more than this combination (Paul's are different). So how 
many combinations are we willing to add here? Seems like that could get 
out of hand if there are more than a few invalid combinations. Would we 
also want to restrict the workaround to specific hardware/firmware?
>