Hi Bob, Do you mind testing this patch? Reproduce again with the same ftrace and sniffer logs By the result we can differentiate which is the case: (1) AP sends incorrect CCMP header (less likely) (2) DMA incomplete at some moment, but later the correct data can be retrieved (3) DMA incomplete, data never recovers IIUC, our hardware writes payload first then the tag. The RO attribute is never set in our TLP, so despite the configuration space, PCIE RC shouldn't do reordering. I am waiting for protocol analyzer to verify this, and will update when I have the result. If the buffer poisoning somehow changes the timing, and fail becomes not reproducible, please let us know, thanks! -----Original Message----- From: Robert Beckett Sent: Thursday, October 22, 2026 8:31 PM To: Ping-Ke Shih Cc: linux-wireless@vger.kernel.org; Luka Gejak ; Bitterblue Smith ; Timlee ; matthew.leach@collabora.com; kernel@collabora.com Subject: RE: rtw88: 8822CE passes corrupted A-MSDUs as hw-decrypted, poisoning CCMP replay counter External mail : This email originated from outside the organization. Do not reply, click links, or open attachments unless you recognize the sender and know the content is safe. From: Ping-Ke Shih To: "Bob Beckett" Cc: "linux-wireless@vger.kernel.org", "Luka Gejak", "Bitterblue Smith", "Timlee", "matthew.leach@collabora.com", "kernel@collabora.com" Date: Thu, 22 Oct 2026 06:39:55 +0100 Subject: RE: rtw88: 8822CE passes corrupted A-MSDUs as hw-decrypted, poisoning CCMP replay counter > Bob Beckett wrote: > > On Wed, 21 Oct 2026 07:30:58 +0000, Ping-Ke Shih wrote: > > > Bob Beckett wrote: > > > > > > > > The AP's own PN sequence is consistent before and after the bad frame, > > > > so the corruption happens on the receive side. > > > > > > Maybe this is a hint to make a patch to defer (drop) reporting weird packet, > > > as Luka has fixed 3 of 4 problems. > > I quickly checked the debug patches, which seem not detect if PN sequence is > correct after the bad frame, for example > seq PN > 1 101 > 2 99999 // bad frame. should be 102. > 3 103 // not detect this > > Or I missed something? if pn jumps, rtw_rx_pn_guard returns early before latching pn, so the next corrected pn would just be a regular increase and not get dropped. > > > > > 4. For completeness: on these chips can RXBD_IDX or the > > > > buffer-descriptor RX tag ever be updated before the packet data DMA > > > > has completed, as described for WiFi 7 in rtw89 0bc7d1d4e63c? > > > > > > The RX tag in rtw88 located on memory allocated by dma_alloc_coherent(), and > > > the RX tag must be set after packet data MAC completed. > > (fix typo: ... data DMA completed.) > > > > > Understood that this is the design intent. My question was whether the host can > > ever observe the tag before the data. dma_alloc_coherent() only makes the tag > > visible to the CPU without cache maintenance; the payload is in a separate > > streaming mapping (a SWIOTLB bounce buffer on this platform), so the order in > > which the host sees them depends on the order of the device's PCIe writes. > > Relaxed Ordering is enabled on the 8822CE here (DevCtl RlxdOrd+). > > Does the 8822CE set the RO attribute on RX DMA writes, in particular the > > buffer-descriptor/tag update? If it does, the tag write may pass the payload > > writes. > > > > We are hoping to test this directly with the next round of tests. the rx_debug > > option re-syncs a suspect buffer 100 us later, so late payload writes might > > show up as changed bytes, and we can repeat the test with Relaxed Ordering > > disabled. > > I'll check the behavior internally and get back to you. > > >