linux-kernel - Re: [PATCH 1/3] wifi: ath11k: fix dest ring-buffer corruption

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: <03354d56-ed21-47e0-a52e-14f559ff3bfb@quicinc.com>
Date: Thu, 5 Jun 2025 12:01:29 +0800
From: Miaoqing Pan <quic_miaoqing@...cinc.com>
To: Jeff Johnson <jeff.johnson@....qualcomm.com>,
        Johan Hovold
	<johan@...nel.org>,
        Baochen Qiang <quic_bqiang@...cinc.com>
CC: Johan Hovold <johan+linaro@...nel.org>,
        Jeff Johnson
	<jjohnson@...nel.org>, <linux-wireless@...r.kernel.org>,
        <ath11k@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <stable@...r.kernel.org>
Subject: Re: [PATCH 1/3] wifi: ath11k: fix dest ring-buffer corruption



On 6/5/2025 12:24 AM, Jeff Johnson wrote:
> On 6/3/2025 7:34 PM, Miaoqing Pan wrote:
>> We previously had extensive discussions on this topic in the
>> https://lore.kernel.org/linux-wireless/ecfe850c-b263-4bee-b888-c34178e690fc@quicinc.com/
>> thread. On my platform, dma_rmb() did not work as expected. The issue
>> only disappeared after disabling PCIe endpoint relaxed ordering in
>> firmware side. So it seems that HP was updated (Memory write) before
>> descriptor (Memory write), which led to the problem.
> 
> Have all ath11k and ath12k firmware been updated to prevent this problem from
> the firmware side?
> 
No, as this is not a widespread issue, and addressing it would require 
modifying the core underlying modules of the firmware. Therefore, we 
chose not to proceed with that approach but instead used the workaround 
patch I previously submitted.

> Or do we need both the barriers and the logic to retry reading the descriptor?
> 

I think so, that would be best.