CVE-2026-98805: Linux Kernel TIPC GCM Nonce Reuse Vulnerability

CVE-2026-98805 Overview

CVE-2026-98805 is a cryptographic vulnerability in the Linux kernel's Transparent Inter-Process Communication (TIPC) subsystem. The flaw allows AES-GCM nonce reuse when a peer reports a change in its receive key. TIPC resets the per-peer counter stored in the receive crypto object while the sender continues using the same transmit key and salt. Subsequent packets reuse earlier nonces under the same key, breaking confidentiality and exposing the GCM authentication key. An attacker who recovers the authentication key can forge valid tags for modified ciphertexts by exploiting counter-mode malleability.

Critical Impact
Nonce reuse under the same AES-GCM key enables plaintext recovery and trivial packet forgery between TIPC nodes using per-node transmit keys.

Affected Products

Linux kernel TIPC subsystem (crypto path for per-node transmit keys)
Stable kernel branches referenced by the fix commits
Deployments using TIPC with AES-GCM encryption between nodes

Discovery Timeline

2026-10-18 - CVE-2026-98805 published to NVD
2026-10-21 - Last updated in NVD database

Technical Details for CVE-2026-98805

Vulnerability Analysis

TIPC encrypts inter-node traffic with AES-GCM and supports a mode where each peer uses a distinct transmit key. The 96-bit GCM nonce consists of a 32-bit prefix formed by XOR of a per-key salt with the peer's address, followed by a 64-bit counter. The counter for packets destined to a given peer lives inside that peer's RX crypto object.

When a peer sends a key-status report announcing a change in its receive key, TIPC resets the counter in the peer's RX crypto object. The transmitting node, however, may still be using the same TX key and salt. Resetting the counter while the key and salt remain unchanged causes the same (key, nonce) pair to be used for different plaintexts. AES-GCM provides no security guarantees under nonce reuse: confidentiality collapses and the GHASH authentication key becomes recoverable from two ciphertexts sharing a nonce.

Once an attacker extracts the authentication key, they can modify intercepted ciphertexts using CTR malleability and compute a valid GCM tag for the altered content. This permits silent packet forgery that passes authentication checks on the receiver.

Root Cause

The counter used to build GCM nonces was stored per-peer in the RX crypto object and was reset on peer key-status transitions. The reset was decoupled from the lifetime of the TX key and salt that together with the counter form the nonce. Because the counter is one component of a nonce whose other components do not change, resetting it alone violates the GCM uniqueness requirement.

Attack Vector

An attacker positioned on the TIPC network path captures encrypted traffic between two nodes. By inducing or waiting for a peer key-status change that triggers the counter reset, the attacker collects ciphertexts encrypted under the same TX key with repeating nonces. The attacker recovers the GHASH authentication key from the colliding nonces and forges arbitrary modifications to captured ciphertexts, which the receiver accepts as authentic.

The vulnerability is described in the upstream commit messages. See the Kernel Git Commit 512ccd3 for the fix and reasoning.

Detection Methods for CVE-2026-98805

Indicators of Compromise

Unexpected or repeated TIPC peer key-status change messages correlated with unchanged TX key material on the sender
Elevated volumes of TIPC traffic followed by anomalous application-layer behavior on receiving nodes that could indicate accepted forged packets
Kernel log entries referencing TIPC crypto key activation, revocation, or counter wrap events

Detection Strategies

Audit running kernel versions against the fixed commits referenced in the advisory to identify unpatched nodes using TIPC encryption
Instrument TIPC-enabled hosts to log key activation and peer key-status transitions and alert on abnormal frequency
Capture and compare GCM nonce prefixes across sessions in controlled test environments to validate that the fix is applied

Monitoring Recommendations

Monitor kernel ring buffer output (dmesg) and syslog for TIPC subsystem messages related to crypto state changes
Track configuration changes to TIPC bearers and key material via configuration management tooling
Alert on unexpected TIPC peer reconnection patterns on hosts where TIPC is enabled

How to Mitigate CVE-2026-98805

Immediate Actions Required

Apply the upstream kernel patch set referenced in the advisory and reboot affected nodes
Inventory hosts with the TIPC module loaded and determine whether per-node encryption is in use
Where patching is delayed, disable TIPC encryption or unload the TIPC module on hosts that do not require it

Patch Information

The fix changes the nonce counter source from the per-peer RX counter to the TX key's existing aead->seqno atomic counter. All encryptions under the same TX key share this counter, which survives key activation and peer reconnection and cannot be reset by peer key-status reports. The nonce format on the wire is unchanged and receivers tolerate non-consecutive counter values, preserving interoperability. A pre-existing check still triggers key revocation if the counter wraps to zero. The upstream commits implementing the fix are available at Kernel Git Commit 512ccd3, Kernel Git Commit 5c8ce13, Kernel Git Commit 60e0c2a, Kernel Git Commit a85a3dc, and Kernel Git Commit f74f100.

Workarounds

Blacklist the tipc kernel module on systems that do not require TIPC
Disable TIPC encryption where confidentiality can be provided by an alternate transport such as IPsec
Restrict TIPC bearer interfaces to trusted network segments to limit attacker access to encrypted traffic

bash

# Prevent the TIPC module from loading on hosts that do not require it
echo 'install tipc /bin/true' | sudo tee /etc/modprobe.d/disable-tipc.conf
sudo rmmod tipc 2>/dev/null || true

# Verify the module is not loaded
lsmod | grep -i tipc