netdev - Re: [net 1/1] tipc: fix problems with multipoint-to-point flow control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20180102.215227.1836995198743909376.davem@davemloft.net>
Date:   Tue, 02 Jan 2018 21:52:27 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     jon.maloy@...csson.com
Cc:     netdev@...r.kernel.org,
        mohan.krishna.ghanta.krishnamurthy@...csson.com,
        tung.q.nguyen@...tech.com.au, hoang.h.le@...tech.com.au,
        canh.d.luu@...tech.com.au, ying.xue@...driver.com,
        tipc-discussion@...ts.sourceforge.net
Subject: Re: [net 1/1] tipc: fix problems with multipoint-to-point flow
 control

From: Jon Maloy <jon.maloy@...csson.com>
Date: Fri, 29 Dec 2017 19:48:02 +0100

> In commit 04d7b574b245 ("tipc: add multipoint-to-point flow control") we
> introduced a protocol for preventing buffer overflow when many group
> members try to simultaneously send messages to the same receiving member.
> 
> Stress test of this mechanism has revealed a couple of related bugs:
> 
> - When the receiving member receives an advertisement REMIT message from
>   one of the senders, it will sometimes prematurely activate a pending
>   member and send it the remitted advertisement, although the upper
>   limit for active senders has been reached. This leads to accumulation
>   of illegal advertisements, and eventually to messages being dropped
>   because of receive buffer overflow.
> 
> - When the receiving member leaves REMITTED state while a received
>   message is being read, we miss to look at the pending queue, to
>   activate the oldest pending peer. This leads to some pending senders
>   being starved out, and never getting the opportunity to profit from
>   the remitted advertisement.
> 
> We fix the former in the function tipc_group_proto_rcv() by returning
> directly from the function once it becomes clear that the remitting
> peer cannot leave REMITTED state at that point.
> 
> We fix the latter in the function tipc_group_update_rcv_win() by looking
> up and activate the longest pending peer when it becomes clear that the
> remitting peer now can leave REMITTED state.
> 
> Signed-off-by: Jon Maloy <jon.maloy@...csson.com>

Applied, thanks Jon.