In the Linux kernel, the following vulnerability has been resolved: macsec: fix replay protection at XPN lower-PN wrap In macsec_post_decrypt(),… (CVE-2026-63925)
In the Linux kernel, the following vulnerability has been resolved: macsec: fix replay protection at XPN lower-PN wrap In macsec_post_decrypt(), when pn is U32_MAX, pn + 1 overflows u32 to 0 and the first branch never fires. If next_pn_halves.lower is also in the upper half, pn_same_half(pn, lower) is true and the XPN else-if does not fire either, leaving next_pn_halves unchanged. An attacker that captures the legitimate frame carrying pn == 0xFFFFFFFF on an XPN association can then replay it indefinitely, since lowest_pn never rises above the captured pn and macsec_decrypt() reconstructs the same IV. Extend the XPN else-if to also fire when pn + 1 wraps to 0, so receipt of pn == U32_MAX advances next_pn_halves to (upper + 1, 0).
AI Analysis
Technical Summary
The Linux kernel macsec module had a flaw in its replay protection mechanism for Extended Packet Number (XPN) associations. Specifically, when the packet number reaches the maximum 32-bit unsigned integer value (U32_MAX), incrementing it causes an overflow to zero, but the existing logic did not update the replay protection state accordingly. This allowed an attacker who captured a legitimate frame with pn == 0xFFFFFFFF to replay it indefinitely, as the lowest packet number never advanced and the decryption initialization vector (IV) was reconstructed identically. The fix involved modifying the XPN else-if condition to handle the wrap-around case, ensuring that receipt of pn == U32_MAX properly advances the replay protection state.
Potential Impact
An attacker capable of capturing a legitimate macsec frame with the maximum packet number could replay that frame indefinitely, bypassing replay protection. This undermines the integrity guarantees of macsec by allowing replayed frames to be accepted and decrypted as valid, potentially leading to unauthorized data injection or replay attacks on the protected network traffic.
Mitigation Recommendations
A fix for this vulnerability has been implemented in the Linux kernel macsec code. Users should apply the official kernel updates that include this patch. Since no specific patch versions are provided, check the vendor or Linux kernel security advisories for the relevant fixed kernel versions and update accordingly.
In the Linux kernel, the following vulnerability has been resolved: macsec: fix replay protection at XPN lower-PN wrap In macsec_post_decrypt(),… (CVE-2026-63925)
Description
In the Linux kernel, the following vulnerability has been resolved: macsec: fix replay protection at XPN lower-PN wrap In macsec_post_decrypt(), when pn is U32_MAX, pn + 1 overflows u32 to 0 and the first branch never fires. If next_pn_halves.lower is also in the upper half, pn_same_half(pn, lower) is true and the XPN else-if does not fire either, leaving next_pn_halves unchanged. An attacker that captures the legitimate frame carrying pn == 0xFFFFFFFF on an XPN association can then replay it indefinitely, since lowest_pn never rises above the captured pn and macsec_decrypt() reconstructs the same IV. Extend the XPN else-if to also fire when pn + 1 wraps to 0, so receipt of pn == U32_MAX advances next_pn_halves to (upper + 1, 0).
CVSS v3.1
Score 8.1high
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel macsec module had a flaw in its replay protection mechanism for Extended Packet Number (XPN) associations. Specifically, when the packet number reaches the maximum 32-bit unsigned integer value (U32_MAX), incrementing it causes an overflow to zero, but the existing logic did not update the replay protection state accordingly. This allowed an attacker who captured a legitimate frame with pn == 0xFFFFFFFF to replay it indefinitely, as the lowest packet number never advanced and the decryption initialization vector (IV) was reconstructed identically. The fix involved modifying the XPN else-if condition to handle the wrap-around case, ensuring that receipt of pn == U32_MAX properly advances the replay protection state.
Potential Impact
An attacker capable of capturing a legitimate macsec frame with the maximum packet number could replay that frame indefinitely, bypassing replay protection. This undermines the integrity guarantees of macsec by allowing replayed frames to be accepted and decrypted as valid, potentially leading to unauthorized data injection or replay attacks on the protected network traffic.
Mitigation Recommendations
A fix for this vulnerability has been implemented in the Linux kernel macsec code. Users should apply the official kernel updates that include this patch. Since no specific patch versions are provided, check the vendor or Linux kernel security advisories for the relevant fixed kernel versions and update accordingly.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-9hhm-2pf7-p38c
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-63925"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- 3.1
Threat ID: 6a5d27ab2a4a8d598912f24d
Added to database: 07/19/2026, 19:38:19 UTC
Last enriched: 07/19/2026, 20:07:39 UTC
Last updated: 08/30/2026, 10:52:10 UTC
Views: 58
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.