PT-2026-116769 · Linux · Linux
CVE-2026-98550
·
Publicado
2026-10-18
·
Atualizado
2026-10-18
Nenhuma
Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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:
-
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.
-
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.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux