CVE-2026-98550 in Linux
Summary
by MITRE • 10/18/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The Transmission Control Protocol over IP, commonly known as TIPC, is a suite of protocols designed for communication between processes within clustered systems and across clusters via standard networking infrastructure. Within the Linux kernel implementation of this protocol stack, a critical logic flaw exists in the handling of group acknowledgment messages during broadcast operations. This vulnerability stems from insufficient validation checks when processing GRP_ACK_MSG packets, which are used by cluster members to confirm receipt of broadcast data. The core issue involves an integer underflow condition affecting the bc_ackers counter, a 16-bit unsigned integer that tracks the number of pending acknowledgments required for a specific broadcast round. This flaw allows unexpected or stale acknowledgment messages to bypass existing duplicate detection logic, leading to incorrect state transitions within the TIPC group management subsystem and potentially causing denial-of-service conditions for cluster communication services.
The first manifestation of this vulnerability occurs when the bc_ackers counter is already at zero. In scenarios where a group is quiet, replicast acknowledgments were not requested by the sender, or all expected members have previously acknowledged their receipt of data, the system expects no further acknowledgment packets to be relevant for that specific broadcast cycle. However, if an unexpected GRP_ACK_MSG arrives with an acked value greater than the currently tracked m->bc_acked value, it passes through a less-than-or-equal check designed only to filter out exact duplicates. Because bc_ackers is defined as an unsigned 16-bit integer, decrementing it when it is already zero causes it to wrap around to its maximum value of sixty-five thousand five hundred thirty-five. This massive artificial inflation of the pending acknowledgment count triggers a false positive in congestion detection logic. Specifically, the tipc_group_bc_cong function interprets this inflated counter as an indication that the network or group is congested, leading to the permanent blocking of all future broadcast transmissions on the affected socket until the state is manually reset or the node restarts.
The second aspect of the vulnerability involves a sequence space gap during active broadcast rounds where bc_ackers is greater than zero. During normal operation, when a sender transmits packet S and advances its send next sequence number to S plus one, receivers increment their expected counter upon consuming that packet. Theoretically, only an acknowledgment matching exactly grp->bc_snd_nxt should be valid for the current round. However, due to initialization logic in tipc_group_update_bc_members, each member's m->bc_acked is set to prev equaling grp->bc_snd_nxt minus one. This creates a two-sequence gap between S minus one and S plus one. Consequently, an incoming acknowledgment with value S or other unexpected values within this gap are not rejected as duplicates nor prevented from decrementing the global bc_ackers counter. A malicious or misbehaving member could send acked equal to S followed by acked equal to S plus one, effectively double-decrementing the group's pending acknowledgment count in a single round. This premature clearing of bc_ackers can lead to race conditions where subsequent broadcast operations proceed without proper synchronization guarantees, potentially causing data loss or protocol state desynchronization among cluster nodes.
From a security architecture perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound and CWE-20 Improper Input Validation. The failure to strictly validate the sequence number against the expected next send value allows an attacker who can inject packets into the TIPC communication channel to manipulate internal state counters. In the context of MITRE ATT&CK, this behavior relates to techniques involving resource exhaustion (T1499) and potential disruption of service availability by manipulating protocol states to trigger false congestion controls or desynchronize cluster members. The impact is primarily a denial-of-service condition for TIPC-based applications relying on reliable broadcast delivery within the Linux kernel environment.
To mitigate this vulnerability, the recommended approach involves applying the upstream kernel patch that enforces stricter validation rules for GRP_ACK_MSG processing. Specifically, implementations must drop any incoming acknowledgment message immediately if the group's bc_ackers counter is zero, as no further acknowledgments are expected or valid in that state. Furthermore, during active broadcast rounds, systems must require that the acked value strictly equals grp->bc_snd_nxt and reject any duplicates where m->bc_acked matches the received acked value. This ensures that each member can acknowledge at most once per round and prevents the underflow condition caused by stale or out-of-sequence packets. Administrators should ensure their Linux kernels are updated to versions containing these fixes, particularly for systems relying on TIPC for high-availability clustering or inter-process communication where broadcast integrity is critical.