CVE-2026-98550: tipc: reject invalid and unexpected GRP_ACK_MSG to prevent bc_ackers underflow
In the Linux kernel, the following vulnerability has been resolved:
tipc: reject invalid and unexpected GRPACKMSG to prevent bcackers underflow
Commit 48a5fe38772b ("tipc: fix bcackers underflow on duplicate GRPACKMSG") rejected duplicate/stale ACKs in tipcgroupprotorcv() by returning early when lesseq(acked, m->bcacked).
However, that check remains incomplete in two ways:
1. When grp->bcackers is zero (e.g. on a quiet group, when replicast ACKs were not requested, or after all expected members have already acknowledged), an unexpected GRPACKMSG with acked > m->bcacked passes lesseq() and unconditionally decrements grp->bcackers. Because bcackers is a u16, this wraps to 65535, causing tipcgroupbccong() to permanently report congestion and blocking all future group broadcasts on the socket.
2. During an active broadcast round (grp->bcackers > 0), the sender transmits packet S and advances grp->bcsndnxt 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->bcsndnxt.
However, tipcgroupupdatebcmembers() initializes each member's m->bcacked to prev = grp->bcsndnxt - 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->bcackers if an unexpected or stale value (such as S) is received. A member sending acked = S followed by acked = S + 1 could decrement grp->bcackers twice in the same round, prematurely clearing bcackers or underflowing it.
Fix this by: - Dropping GRPACKMSG immediately if grp->bcackers is zero. - Requiring acked == grp->bcsndnxt and rejecting duplicates where m->bcacked == acked. Because replicast broadcast rounds are strictly sequential, only grp->bcsndnxt can be acknowledged, and each member can acknowledge at most once per round.
Note that a related pre-existing issue in tipcgroupdeletemember() (where grp->bcackers decrementing to zero upon member departure does not restore grp->open or trigger a socket wakeup) will be addressed in a separate patch.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.159.1-1 - Upgrade
Upgrade
azurelinux/kernelto a version that resolves this vulnerability.Fixed in 6.6.159.1-1 - Upgrade
Upgrade
ubuntu/linux-aws-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1119.126~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1125.134~20.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1124.133~20.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1120.130~20.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-202.212~20.04.1 - Upgrade
Upgrade
ubuntu/linux-ibm-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1113.117~20.04.1 - Upgrade
Upgrade
ubuntu/linux-intel-iotg-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1114.120~20.04.1 - Upgrade
Upgrade
ubuntu/linux-lowlatency-hwe-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-197.207~20.04.1 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegra-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1070.72~20.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1116.122~20.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-5.15to a version that resolves this vulnerability.Fixed in 5.15.0-1113.117~20.04.2 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 5.15.0-202.212 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 5.15.0-1119.126 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 5.15.0-1125.134 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 5.15.0-1124.133 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 5.15.0-1120.130 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 5.15.0-1115.121 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 5.15.0-1102.110 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 5.15.0-1113.117 - Upgrade
Upgrade
ubuntu/linux-intel-iotgto a version that resolves this vulnerability.Fixed in 5.15.0-1114.120 - Upgrade
Upgrade
ubuntu/linux-kvmto a version that resolves this vulnerability.Fixed in 5.15.0-1111.116 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 5.15.0-197.207 - Upgrade
Upgrade
ubuntu/linux-nvidiato a version that resolves this vulnerability.Fixed in 5.15.0-1114.115 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 5.15.0-1070.72 - Upgrade
Upgrade
ubuntu/linux-nvidia-tegra-igxto a version that resolves this vulnerability.Fixed in 5.15.0-1059.59 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 5.15.0-1116.122 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 5.15.0-1103.105 - Upgrade
Upgrade
ubuntu/linux-intel-iot-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1111.115 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 5.15.0-1118.127 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1119.126+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1125.134+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-202.212+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 5.15.0-1120.130+fips1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1 - Compensating control
In Linux kernel TIPC GRP_ACK_MSG handling, drop the message immediately when grp->bc_ackers is zero; otherwise accept an ACK only when acked == grp->bc_snd_nxt and reject duplicate ACKs where m->bc_acked == acked, preventing invalid ACKs from decrementing grp->bc_ackers.
Event History
Frequently Asked Questions
What conditions make a system susceptible to this issue?
The affected path is TIPC group broadcast handling. It can be triggered when a TIPC group receives an invalid or unexpected GRP_ACK_MSG, including when no broadcast acknowledgers are expected or after all expected members have acknowledged.
What is the practical impact if exploitation succeeds?
The group broadcast acknowledgment counter can underflow and wrap to 65535. TIPC then permanently reports broadcast congestion for the affected socket, blocking all future group broadcasts on that socket.
Does an attacker need to send a normal duplicate acknowledgment?
No. Duplicate or stale acknowledgments were already checked, but the described flaw involves unexpected acknowledgments that can pass that existing check, including an ACK when bc_ackers is zero or an ACK value invalid for the active broadcast round.
How can I tell whether a socket has been affected?
The described observable result is that TIPC group broadcasts on the affected socket remain blocked because congestion is permanently reported. The counter wraps to 65535 when the underflow occurs.