CVE-2026-63925

What it actually does

This flaw affects Linux kernel MACsec Extended Packet Number (XPN) replay protection. When a received MACsec frame has a packet number of 0xFFFFFFFF, the kernel incorrectly handles the lower 32-bit packet-number wraparound. Because the replay window state is not advanced to the next upper packet-number half, a previously captured legitimate encrypted frame with that exact packet number can be accepted repeatedly instead of being rejected as a replay. The result is a MAC-layer integrity failure and potential availability impact on MACsec-protected links using XPN.

Why it matters to the business

Organizations relying on Linux MACsec for link-layer protection could have protected network traffic replayed by an attacker with access to the same network segment or physical/link-adjacent position. This can undermine trust in MACsec-protected communications, potentially causing repeated commands, duplicated traffic effects, service disruption, or protocol-level confusion in systems that assume MACsec prevents replay. The issue is high severity, but exploitation requires the attacker to observe or capture a very specific legitimate frame on an affected MACsec XPN association.

How an attack unfolds

An attacker must be in an adjacent network position where they can observe MACsec-protected traffic on a link using XPN. The attacker monitors traffic until a legitimate frame is transmitted with the lower packet number equal to 0xFFFFFFFF. They capture that encrypted frame and later retransmit it. Due to the kernel replay-protection bug, the receiver does not correctly advance its replay state when processing that wraparound packet number. As a result, the same captured frame may be accepted repeatedly instead of being discarded as a replay. The attacker does not need credentials or user interaction, but they do need link-level access and the ability to capture and inject frames on the MACsec-protected segment.

How to fix it

Apply a Linux kernel update that includes the MACsec XPN replay-protection fix for macsec_post_decrypt(). Because no product-specific fixed versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution, appliance vendor, or upstream stable kernel branch. Prioritize systems that enable MACsec with Extended Packet Number support on production links. If immediate patching is not possible, reduce exposure by disabling MACsec XPN where operationally feasible, rotating MACsec Secure Associations before packet numbers approach wrap conditions, limiting physical and Layer-2 access to MACsec links, and monitoring for repeated MACsec frames around packet-number wrap boundaries. Mitigations should be treated as temporary; kernel patching is the durable fix.

How to confirm the fix worked

Confirm that each affected system is running a kernel build containing the MACsec XPN wraparound replay-protection fix. Validate exposure by checking whether MACsec is configured and whether XPN is in use on network interfaces. On Linux systems, review `ip macsec show` output for MACsec interfaces, Secure Channels, Secure Associations, replay protection, and XPN-related configuration. If possible, test in a lab by replaying a captured MACsec XPN frame at the lower packet-number wrap boundary and confirming that the patched receiver advances state correctly and rejects subsequent replays. Also confirm that distribution security advisories or kernel changelogs reference the MACsec XPN replay-protection fix.

Typical attack path

1. Gain adjacent access to a network path carrying Linux MACsec-protected traffic using XPN.
2. Passively monitor MACsec frames for a target Secure Association and packet-number sequence.
3. Capture a legitimate frame where the lower packet number reaches 0xFFFFFFFF.
4. Replay the captured frame back onto the MACsec-protected link.
5. Rely on the vulnerable receiver failing to advance replay-protection state across the lower packet-number wrap.
6. Repeat the replay to cause integrity violations or operational disruption depending on the encapsulated traffic.

How to detect it

Look for evidence of replayed MACsec traffic on links using XPN, especially repeated frames with the same Secure Channel Identifier, Association Number, and packet number at or near 0xFFFFFFFF. Useful data sources include packet captures from taps or SPAN ports on MACsec links, Linux MACsec interface state from `ip macsec show`, kernel/network logs, interface error counters, and any switch or appliance telemetry that records MACsec replay-window events. Because successful exploitation occurs at Layer 2 and may not generate application logs, packet-level evidence is the strongest source. Investigate repeated encrypted MACsec frames with identical MACsec headers, unexpected duplicate downstream effects, replay counter anomalies, unexplained MACsec receiver state inconsistencies, or traffic bursts immediately after packet-number wrap conditions. If threat hunting after a suspected event, preserve packet captures, kernel versions, MACsec configuration, Secure Association rotation history, and interface counters before restarting or rekeying links.

• Repeated MACsec XPN frames with identical SCI, AN, and PN=0xffffffff
• Multiple accepted MACsec frames using the same lower packet number 0xffffffff on the same Secure Association
• MACsec replay activity clustered around PN 0xffffffff
• Unexpected duplicate MACsec-protected frames immediately after lower packet-number wrap
• ip macsec show
• macsec_post_decrypt
• PN=0xffffffff
• 0xFFFFFFFF

What your security team should do

• Inventory Linux systems, appliances, and network hosts that use MACsec, especially links configured with Extended Packet Numbers.
• Prioritize kernel updates for systems on untrusted, shared, physically exposed, or high-value Layer-2 network segments.
• Request fixed kernel packages or advisories from Linux distribution and appliance vendors where exact fixed versions are not yet known.
• Review MACsec operational telemetry for packet-number wrap behavior, repeated frames, or unexpected replay-window anomalies.
• Restrict physical and Layer-2 access to MACsec-protected links to reduce the chance of capture-and-replay attacks.
• If patching is delayed, consider rotating Secure Associations before lower packet numbers approach 0xFFFFFFFF or disabling XPN where feasible and safe.
• Add detection coverage for repeated MACsec XPN frames with identical SCI, association number, and packet number at the wrap boundary.
• Document residual risk for MACsec-protected environments where link-adjacent attackers are plausible.