CVE-2026-98550 in Linux
Zusammenfassung
von VulDB • 18.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
tipc: Verwerfen ungültiger und unerwarteter GRP_ACK_MSG-Pakete, um ein Underflow von bc_ackers zu verhindern
Das Commit 48a5fe38772b („tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG“) hat doppelte/veraltete ACKs in tipc_group_proto_rcv() abgewiesen, indem es bei less_eq(acked, m->bc_acked) vorzeitig zurückkehrte.
Diese Prüfung ist jedoch auf zwei Arten unvollständig:
1. Wenn grp->bc_ackers null ist (z. B. in einer ruhigen Gruppe, wenn Replicast-ACKs nicht angefordert wurden oder nachdem alle erwarteten Mitglieder bereits bestätigt haben), passiert ein unerwartetes GRP_ACK_MSG mit acked > m->bc_acked die less_eq()-Prüfung und dekrementiert grp->bc_ackers bedingungslos. Da bc_ackers eine u16 ist, führt dies zu einem Wrap-Around auf 65535, wodurch tipc_group_bc_cong() dauerhaft Stau meldet und alle zukünftigen Gruppen-Broadcasts im Socket blockiert werden.
2. Während einer aktiven Broadcast-Runde (grp->bc_ackers > 0) sendet der Sender das Paket S und erhöht grp->bc_snd_nxt auf S + 1. Empfänger erhöhen ihren erwarteten Zähler bei Verbrauch von Paket S um eins, sodass der einzige gültige ACK-Wert für die aktuelle Runde streng genommen acked == grp->bc_snd_nxt ist.
Allerdings initialisiert tipc_group_update_bc_members() m->bc_acked jedes Mitglieds auf prev = grp->bc_snd_nxt - 1 (S - 1 vor dem Inkrement). Dies hinterlässt eine Lücke von 2 Sequenzen (von S - 1 bis S + 1) im Sequenzraum. Ein eingehender ACK wird daher weder als doppelt gemeldet abgewiesen, noch wird verhindert, dass er grp->bc_ackers dekrementiert, wenn ein unerwarteter oder veralteter Wert (wie z. B. S) empfangen wird. Ein Mitglied, das acked = S gefolgt von acked = S + 1 sendet, könnte grp->bc_ackers in derselben Runde zweimal dekrementieren und dadurch bc_ackers vorzeitig löschen oder ein Underflow verursachen.
Beheben Sie dies durch: - Sofortiges Verwerfen von GRP_ACK_MSG, wenn grp->bc_ackers null ist. - Erfordern von acked == grp->bc_snd_nxt und Ablehnen von Duplikaten, bei denen m->bc_acked == acked gilt. Da Replicast-Broadcast-Runden streng sequentiell sind, kann nur grp->bc_snd_nxt bestätigt werden, und jedes Mitglied kann pro Runde höchstens einmal bestätigen.
Beachten Sie, dass ein verwandtes, bereits bestehendes Problem in tipc_group_delete_member() (bei dem das Dekrementieren von grp->bc_ackers auf null beim Ausscheiden eines Mitglieds *grp->open nicht wiederherstellt oder einen Socket-Wakeup auslöst) in einem separaten Patch behandelt wird.
If you want to get best quality of vulnerability data, you may have to visit VulDB.