RE: rtw88: 8822CE passes corrupted A-MSDUs as hw-decrypted, poisoning CCMP replay counter

[Bernie Huang <phhuang@realtek.com>]

>  > Bob Beckett <bob.beckett@collabora.com> wrote:
>  > > On Wed, 21 Oct 2026 07:30:58 +0000, Ping-Ke Shih
> <pkshih@realtek.com> wrote:
>  > > > Bob Beckett <bob.beckett@collabora.com> 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.
>  >
>  >
>  >
> 

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!