Cloudanix VulnDB

CVE-2026-98550

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux kernel's TIPC messaging code lets an attacker send special messages that permanently break group communication on affected systems.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

An attacker can send crafted or unexpected GRP_ACK_MSG packets that cause bc_ackers to underflow from zero to 65535, making tipc_group_bc_cong() permanently report congestion and block all future group broadcasts on the affected socket.

Why it matters to the business

Systems relying on TIPC group broadcast messaging experience sudden, persistent loss of reliable group communication, which can disrupt cluster coordination, high-availability services, or real-time data distribution until the kernel is updated or the socket is recreated.

How an attack unfolds

An attacker with network access to a TIPC-enabled system sends one or more GRP_ACK_MSG messages containing sequence numbers that either exceed the current bc_acked value when bc_ackers is already zero or fall inside the small gap created during broadcast round initialization, triggering the underflow without requiring authentication or prior session state.

How to fix it

Upgrade the Linux kernel to a version containing the fix that drops GRP_ACK_MSG when bc_ackers is zero and enforces acked == bc_snd_nxt with duplicate rejection; apply the patch referenced in the commit that adds these early checks in tipc_group_proto_rcv().

How to confirm the fix worked

Confirm the kernel version includes the updated tipc_group_proto_rcv() logic that rejects ACKs when bc_ackers == 0 and requires exact sequence match; test by exercising group broadcast after sending unexpected ACKs and verify bc_ackers never underflows.

Typical attack path

  1. Identify a TIPC group socket that is either idle or in the middle of a broadcast round.
  2. Craft and transmit GRP_ACK_MSG packets with acked values that bypass the existing duplicate/stale checks.
  3. Trigger the unconditional decrement of bc_ackers, causing wrap-around to 65535.
  4. Observe that subsequent broadcast attempts are permanently blocked by the congestion check.

How to detect it

Review kernel logs for TIPC group congestion warnings or bc_ackers anomalies; inspect network captures for unexpected GRP_ACK_MSG packets arriving when no broadcast round is active or with sequence numbers outside the current round.

What your security team should do

  • Prioritize kernel updates on all systems using TIPC group sockets, especially in clustered or distributed environments.
  • Monitor for TIPC-related kernel panics or stalled group communication as an early indicator of exposure.
  • Restrict TIPC traffic to trusted networks until patches are applied, given the low attack complexity.

The record

In the Linux kernel, the following vulnerability has been resolved: tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers underflow Commit 48a5fe38772b ("tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG") rejected duplicate/stale ACKs in tipc_group_proto_rcv() by returning early when less_eq(acked, m->bc_acked). However, that check remains incomplete in two ways: 1. When grp->bc_ackers is zero (e.g. on a quiet group, when replicast ACKs were not requested, or after all expected members have already acknowledged), an unexpected GRP_ACK_MSG with acked > m->bc_acked passes less_eq() and unconditionally decrements grp->bc_ackers. Because bc_ackers is a u16, this wraps to 65535, causing tipc_group_bc_cong() to permanently report congestion and blocking all future group broadcasts on the socket. 2. During an active broadcast round (grp->bc_ackers > 0), the sender transmits packet S and advances grp->bc_snd_nxt to S + 1. Receivers increment their expected counter to S + 1 upon consuming packet S, so the only valid ACK value for the current round is strictly acked == grp->bc_snd_nxt. However, tipc_group_update_bc_members() initializes each member's m->bc_acked to prev = grp->bc_snd_nxt - 1 (S - 1 before increment). This leaves a 2-sequence gap (S - 1 to S + 1) in sequence space. An incoming ACK is therefore neither rejected as duplicate nor prevented from decrementing grp->bc_ackers if an unexpected or stale value (such as S) is received. A member sending acked = S followed by acked = S + 1 could decrement grp->bc_ackers twice in the same round, prematurely clearing bc_ackers or underflowing it. Fix this by: - Dropping GRP_ACK_MSG immediately if grp->bc_ackers is zero. - Requiring acked == grp->bc_snd_nxt and rejecting duplicates where m->bc_acked == acked. Because replicast broadcast rounds are strictly sequential, only grp->bc_snd_nxt can be acknowledged, and each member can acknowledge at most once per round. Note that a related pre-existing issue in tipc_group_delete_member() (where grp->bc_ackers decrementing to zero upon member departure does not restore *grp->open or trigger a socket wakeup) will be addressed in a separate patch.

Affected packages

Ecosystem Package Introduced Fixed