CVE-2026-98550 tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers underflow

High 7.5 Published Updated

An attacker can cause a denial of service in the Linux kernel TIPC module by sending invalid group acknowledgment messages that trigger an integer underflow.

Exploited in the wild
Not known
Login needed
Not needed
Attackable
Over the internet
Victim action needed
Not needed
Fix
Available

What is CVE-2026-98550?

CVE-2026-98550 is a high-severity vulnerability in Linux, published on 18 Oct 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

Official description

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.

Which versions are affected by CVE-2026-98550?

How do I fix CVE-2026-98550?

Apply the vendor's patch.

Is CVE-2026-98550 being exploited?

There is no known exploitation of CVE-2026-98550 in the wild and no public exploit code.

Sources

Also known as AZL-109167, BELL-CVE-2026-98550, DEBIAN-CVE-2026-98550, GHSA-xqp5-j42w-5fq8, UBUNTU-CVE-2026-98550.

Is CVE-2026-98550 in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free