[PATCH net] macsec: prevent AES-GCM nonce reuse after packet number wrap

[PATCH net] macsec: prevent AES-GCM nonce reuse after packet number wrap

[Jérémy Jean]

When MACsec uses 32-bit packet numbers, 0xffffffff is the last valid
packet number, and after allocating it, MACsec deactivates the
transmit SA and wraps the next packet number to zero. Packets already
in flight can still be processed after that.

The first late packet gets packet number zero and is dropped, but
tx_sa_update_pn() has already advanced the stored counter to one before
macsec_encrypt() drops it. A second late packet can then be sent with
packet number one again, reusing the AES-GCM nonce from the start of the
SA.

Keep next_pn at zero after wrap so all late packets are dropped.

Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
---
 drivers/net/macsec.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index 78a19b134632..233391acebb0 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -486,6 +486,9 @@ static pn_t tx_sa_update_pn(struct macsec_tx_sa *tx_sa,
 	spin_lock_bh(&tx_sa->lock);
 
 	pn = tx_sa->next_pn_halves;
+	if (unlikely(pn.full64 == 0))
+		goto out;
+
 	if (secy->xpn)
 		tx_sa->next_pn++;
 	else
@@ -493,6 +496,8 @@ static pn_t tx_sa_update_pn(struct macsec_tx_sa *tx_sa,
 
 	if (tx_sa->next_pn == 0)
 		__macsec_pn_wrapped(secy, tx_sa);
+
+out:
 	spin_unlock_bh(&tx_sa->lock);
 
 	return pn;
-- 
2.47.3

Re: [PATCH net] macsec: prevent AES-GCM nonce reuse after packet number wrap

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] macsec: prevent AES-GCM nonce reuse after packet number wrap

[Sabrina Dubroca]

2026-09-30, 20:33:33 +0000, Jérémy Jean wrote:
> When MACsec uses 32-bit packet numbers, 0xffffffff is the last valid
> packet number

This makes it sound like it's only a problem for 32b packet numbers,
but I think it affects both? Sure it's unlikely with 64b unless we
start from a large offset, but a well-behaved userspace should also
rekey and switch SAs before we ever wrap to avoid losing packets while
the rekey completes (but yes, "losing packets" is not as bad as
"breaking crypto").

> and after allocating it, MACsec deactivates the
> transmit SA and wraps the next packet number to zero. Packets already
> in flight can still be processed after that.

So this is more of a race condition than a full "forever" bug. I think
commit messages should be clear about that (and that doesn't mean it's
not bad or not worth patching, but it's worth mentioning).

Once TX operations hit macsec_encrypt -> macsec_txsa_get and see
!sa->active, packets will be dropped and nonce reuse stops.


> The first late packet gets packet number zero and is dropped, but
> tx_sa_update_pn() has already advanced the stored counter to one before
> macsec_encrypt() drops it. A second late packet can then be sent with
> packet number one again, reusing the AES-GCM nonce from the start of the
> SA.
>
> Keep next_pn at zero after wrap so all late packets are dropped.

"late packet" is defined on the RX side, but it doesn't make sense on
the TX path.

The diff looks good to me.

-- 
Sabrina