Re: [PATCH net] macsec: reject replays after non-XPN receive PN exhaustion
flat view
From: Sabrina Dubroca <sd@queasysnail.net>
Date: 2026-10-08 16:35:43
2026-10-08, 17:25:50 +0900, Sung Byeongchan wrote:
When a non-XPN RXSA accepts PN U32_MAX, advancing the receive PN cannot represent the next value. The replay checks subsequently accept the same authenticated terminal frame again.
And in XPN? I don't see anything checking that .upper didn't wrap, so we'll accept replays of the first chunk of sequence numbers? It also feels strange to have an "exhausted" bit that only ever gets set for !xpn.
Record receive-SA exhaustion after accepting the legitimate terminal frame and reject subsequent frames until userspace explicitly resets the PN. Keep XPN behavior unchanged. Preserve the exhaustion state if a hardware-offload PN update fails and the old PN is restored. The identical terminal-PN frame crossed the controlled port twice in all three baseline runs. All three fixed runs rejected the replay. PN max-1, fresh terminal-frame, and bad-ICV controls retained their expected behavior.
We should also have selftests for all those limit cases (for 32b: exhaustion/wrap, for XPN: both upper32 increase and exhaustion).
quoted hunk ↗ jump to hunk
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c index 78a19b1346321..906108e10b32d 100644 --- a/drivers/net/macsec.c +++ b/drivers/net/macsec.c@@ -750,8 +750,10 @@ static bool macsec_post_decrypt(struct sk_buff *skb, struct macsec_secy *secy, u /* Now perform replay protection check again * (see IEEE 802.1AE-2006 figure 10-5) */ - if (secy->replay_protect && pn < lowest_pn && - (!secy->xpn || pn_same_half(pn, lowest_pn))) { + if (secy->replay_protect && + (rx_sa->exhausted || + (pn < lowest_pn && + (!secy->xpn || pn_same_half(pn, lowest_pn))))) {
The code you're modifying wasn't particularly nice, but this is completely unreadable. And there's another variant of this test written in a slightly different, but also completely unreadable, for the pre-check (well, pn_same_half doesn't take the same reference for some mysterious reason). -- Sabrina