[net 1/1] tipc: fix list sorting bug in function tipc_group_update_member()

[net 1/1] tipc: fix list sorting bug in function tipc_group_update_member()

[Jon Maloy]

When, during a join operation, or during message transmission, a group
member needs to be added to the group's 'congested' list, we sort it
into the list in ascending order, according to its current advertised
window size. However, we miss the case when the member is already on
that list. This will have the result that the member, after the window
size has been decremented, might be at the wrong position in that list.
This again may have the effect that we during broadcast and multicast
transmissions miss the fact that a destination is not yet ready for
reception, and we end up sending anyway. From this point on, the
behavior during the remaining session is unpredictable, e.g., with
underflowing window sizes.

We now correct this bug by unconditionally removing the member from
the list before (re-)sorting it in.

Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
 net/tipc/group.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/tipc/group.c b/net/tipc/group.c
index b96ec42..bbc004e 100644
--- a/net/tipc/group.c
+++ b/net/tipc/group.c
@@ -351,8 +351,7 @@ void tipc_group_update_member(struct tipc_member *m, int len)
 	if (m->window >= ADV_IDLE)
 		return;
 
-	if (!list_empty(&m->congested))
-		return;
+	list_del_init(&m->congested);
 
 	/* Sort member into congested members' list */
 	list_for_each_entry_safe(_m, tmp, &grp->congested, congested) {
-- 
2.1.4

Re: [net 1/1] tipc: fix list sorting bug in function tipc_group_update_member()

[David Miller]

From: Jon Maloy <jon.maloy@ericsson.com>
Date: Mon, 18 Dec 2017 20:03:05 +0100

> When, during a join operation, or during message transmission, a group
> member needs to be added to the group's 'congested' list, we sort it
> into the list in ascending order, according to its current advertised
> window size. However, we miss the case when the member is already on
> that list. This will have the result that the member, after the window
> size has been decremented, might be at the wrong position in that list.
> This again may have the effect that we during broadcast and multicast
> transmissions miss the fact that a destination is not yet ready for
> reception, and we end up sending anyway. From this point on, the
> behavior during the remaining session is unpredictable, e.g., with
> underflowing window sizes.
> 
> We now correct this bug by unconditionally removing the member from
> the list before (re-)sorting it in.
> 
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>

Applied, thanks Jon.