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

["Luka Gejak" <luka.gejak@linux.dev>]

Hi Matthew,

On Mon Oct 19, 2026 at 12:43 PM UTC, Matthew Leach wrote:
> The fresh header followed by unexpected contents is consistent with an
> incomplete write, although I don't think we can distinguish that from
> consuming the buffer before all payload writes are visible. Could we
> compare the RX buffer contents when completion is first observed and
> again before returning the buffer to the hardware? If the contents
> change while the buffer is still host-owned, that would support
> premature completion signalling.

Good idea, but Bob's report says the RX buffers go through SWIOTLB, so
skb->data only gets updated when we call dma_sync_single_for_cpu(). A
late write would stay in the bounce slot and you would never see it
change. The second read needs another dma_sync_single_for_cpu() before
comparing, so doing it only for frames that fail the CCMP header check
keeps it cheap. A run with the IOMMU on would be worth trying too.

The old descriptor in drv_info could also be leftover data from the
device's RX FIFO, which would fit Bob's idea as well.

> However, all four captured bad frames have ICV_ERR clear, so
> checking that bit alone would not catch these examples.

Right, the ICV part doesn't help here, it's only there to match rtw89.
I'll make that clear in v2.

> However, jump 3 has valid reserved/ExtIV bytes (44 50 00 20) and
> corruption in the remaining PN bytes, so this patch would retain
> RX_FLAG_DECRYPTED and still poison the replay counter.

Agreed, it only narrows it. Checking for the LLC/SNAP header after the
first A-MSDU subframe header would catch frame 3 too, but that's a
guess about the payload. I'd rather see what the test shows first,
since that tells us if the fix belongs in the driver or in the device.

Best regards,
Luka Gejak