CVE-2026-98550 in Linux
Resumen
por VulDB • 2026-10-19
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
tipc: rechazar GRP_ACK_MSG inválido e inesperado para prevenir un desbordamiento por defecto (underflow) en bc_ackers
El commit 48a5fe38772b ("tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG") rechazaba ACKs duplicados o obsoletos en tipc_group_proto_rcv() devolviendo la ejecución anticipadamente cuando less_eq(acked, m->bc_acked).
Sin embargo, esa comprobación sigue siendo incompleta de dos maneras:
1. Cuando grp->bc_ackers es cero (por ejemplo, en un grupo inactivo, cuando no se solicitaron ACKs replicast o después de que todos los miembros esperados ya hayan reconocido), un GRP_ACK_MSG inesperado con acked > m->bc_acked supera less_eq() y decrementa incondicionalmente grp->bc_ackers. Dado que bc_ackers es un u16, esto provoca un desbordamiento por defecto (underflow) hasta 65535, lo que hace que tipc_group_bc_cong() informe permanentemente de congestión y bloquee todas las transmisiones grupales futuras en el socket.
2. Durante una ronda de difusión activa (grp->bc_ackers > 0), el remitente transmite el paquete S e incrementa grp->bc_snd_nxt a S + 1. Los receptores incrementan su contador esperado a S + 1 al consumir el paquete S, por lo que el único valor ACK válido para la ronda actual es estrictamente acked == grp->bc_snd_nxt.
Sin embargo, tipc_group_update_bc_members() inicializa m->bc_acked de cada miembro en prev = grp->bc_snd_nxt - 1 (S - 1 antes del incremento). Esto deja un hueco de secuencia de 2 posiciones (de S - 1 a S + 1) en el espacio de secuencias. Por lo tanto, un ACK entrante no se rechaza como duplicado ni se impide que decremente grp->bc_ackers si se recibe un valor inesperado u obsoleto (como S). Un miembro que envíe acked = S seguido por acked = S + 1 podría decrementar grp->bc_ackers dos veces en la misma ronda, borrando prematuramente bc_ackers o provocando su desbordamiento por defecto.
Solucione esto: - Descartando GRP_ACK_MSG inmediatamente si grp->bc_ackers es cero. - Exigiendo acked == grp->bc_snd_nxt y rechazando duplicados donde m->bc_acked == acked. Dado que las rondas de difusión replicast son estrictamente secuenciales, solo se puede reconocer grp->bc_snd_nxt, y cada miembro puede realizar un reconocimiento como máximo una vez por ronda.
Tenga en cuenta que un problema preexistente relacionado en tipc_group_delete_member() (donde el decremento de grp->bc_ackers a cero tras la salida del miembro no restaura *grp->open ni desencadena una activación del socket) se abordará en un parche separado.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.