Cloudanix VulnDB

CVE-2026-98805

None

CVSS

—

EPSS

0.1%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how Linux handles encrypted messages between servers can let someone who sees the traffic read or change it without being detected.

Exploitation
Adjacent Network
Attacker needs
None
Complexity
Moderate
Impact
Data Exposure
Component
OS kernel
Class
Cryptographic Weakness
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Nonce reuse in AES-GCM for TIPC peer traffic when a peer changes receive keys while the sender retains the same TX key and salt, allowing CTR malleability and authentication key recovery that enables trivial ciphertext forgery.

Why it matters to the business

Encrypted node-to-node traffic can be silently read or altered, risking exposure of cluster communications and potential unauthorized control messages in environments relying on TIPC encryption.

How an attack unfolds

An attacker positioned to observe TIPC traffic captures packets during a peer key-change event, identifies nonce reuse under the same key, recovers the authentication key via chosen-ciphertext manipulation, then forges valid packets that decrypt and authenticate correctly at the receiver.

How to fix it

Apply the upstream kernel fix that replaces the per-peer counter with the TX key's existing atomic aead->seqno counter; rebuild and deploy updated kernel images on all systems running TIPC with encryption enabled.

How to confirm the fix worked

Confirm the presence of the shared atomic counter logic in the TIPC crypto transmit path by inspecting kernel source or running a kernel version that includes the nonce-reuse prevention change; test by forcing peer key rotations while monitoring for nonce repetition.

Typical attack path

  1. Position to intercept TIPC traffic between nodes using per-peer AES-GCM keys
  2. Observe or trigger a peer key-status report that resets the receiver-side counter
  3. Capture subsequent packets that reuse earlier nonces with the unchanged TX key
  4. Exploit CTR malleability on recorded ciphertexts to recover the authentication key
  5. Forge modified packets with valid tags under the reused nonce and key

How to detect it

Inspect TIPC packet captures for repeated nonce values under the same key identifier after observed key-status changes; correlate with kernel logs showing peer key activation events and look for anomalous authenticated traffic that deviates from expected sequence behavior.

What your security team should do

  • Prioritize kernel updates on any nodes using TIPC encryption within the next patch cycle given the five-day publication window
  • Disable TIPC encryption or isolate affected clusters until patches are applied if traffic confidentiality is required
  • Review network segmentation and monitoring around TIPC ports to limit exposure while remediation is pending

The record

In the Linux kernel, the following vulnerability has been resolved: tipc: prevent GCM nonce reuse on peer key changes TIPC can encrypt traffic between nodes using a different transmit key for each node. In this mode, the AES-GCM nonce for a packet sent to a known peer consists of a 32-bit prefix (a per-key salt XOR the peer's address) followed by a 64-bit counter. That counter is stored in the peer's RX crypto object. When the peer reports a change in which key it uses to receive packets, TIPC resets this counter. The sender can still be using the same TX key and salt, so subsequent packets reuse earlier nonces. This nonce reuse breaks confidentiality and exposes GCM's authentication key. This makes forgeries trivial: an attacker can exploit CTR malleability to alter captured ciphertexts and use the recovered authentication key to compute a valid tag for the modified ciphertext, under the same key and nonce. Use the TX key's existing aead->seqno counter instead. All encryptions using that key object share the same atomic counter, so concurrent encryptions get distinct nonce counter values. The counter survives key activation and peer reconnection, and peer key-status reports cannot reset it. This prevents those transitions from causing nonce reuse while the same TX key remains installed. The nonce format is unchanged, and receivers do not require consecutive counter values, so sharing the counter across peers remains compatible with existing receivers. A pre-existing check still invokes key revocation in the unlikely event that the counter wraps to zero.

Affected packages

Ecosystem Package Introduced Fixed