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.