linux-kernel - Re: [PATCH v2 ath-next 2/2] wifi: ath11k: fix HTC rx insufficient length

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] [day] [month] [year] [list]

Message-ID: <72d95d77-674e-4ae7-83b0-ab58748b8251@quicinc.com>
Date: Wed, 12 Mar 2025 09:11:45 +0800
From: Miaoqing Pan <quic_miaoqing@...cinc.com>
To: Jeff Johnson <jeff.johnson@....qualcomm.com>,
        Johan Hovold
	<johan@...nel.org>
CC: <ath11k@...ts.infradead.org>, <linux-wireless@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <johan+linaro@...nel.org>
Subject: Re: [PATCH v2 ath-next 2/2] wifi: ath11k: fix HTC rx insufficient
 length



On 3/11/2025 11:20 PM, Jeff Johnson wrote:
> On 3/11/2025 1:29 AM, Miaoqing Pan wrote:
>> On 3/10/2025 6:09 PM, Johan Hovold wrote:
>>> I'm still waiting for feedback from one user that can reproduce the
>>> ring-buffer corruption very easily, but another user mentioned seeing
>>> multiple zero-length descriptor warnings over the weekend when running
>>> with this patch:
>>>
>>> 	ath11k_pci 0006:01:00.0: rxed invalid length (nbytes 0, max 2048)
>>>
>>> Are there ever any valid reasons for seeing a zero-length descriptor
>>> (i.e. unrelated to the race at hand)? IIUC the warning would only be
>>> printed when processing such descriptors a second time (i.e. when
>>> is_desc_len0 is set).
>>>
>>
>> That's exactly the logic, only can see the warning in a second time. For
>> the first time, ath12k_ce_completed_recv_next() returns '-EIO'.
> 
> That didn't answer Johan's first question:
> Are there ever any valid reasons for seeing a zero-length descriptor?
> 
The events currently observed are all firmware logs. The discarded 
packets will not affect normal operation. I will adjust the logging to 
debug level.

> We have an issue that there is a race condition where hardware updates the
> pointer before it has filled all the data. The current solution is just to
> read the data a second time. But if that second read also occurs before
> hardware has updated the data, then the issue isn't fixed.
> 
Thanks for the addition.

> So should there be some forced delay before we read a second time?
> Or should we attempt to read more times?
> 

The initial fix was to keep waiting for the data to be ready. The 
observed phenomenon is that when the second read fails, subsequent reads 
will continue to fail until the firmware's CE2 ring is full and triggers 
an assert after timeout. However, this situation is relatively rare, and 
in most cases, the second read will succeed. Therefore, adding a delay 
or multiple read attempts is not useful.