netdev - Re: [PATCH net 1/1] tipc: eliminate risk of stalled link synchronization

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]

Date:	Wed, 14 Oct 2015 06:07:54 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	jon.maloy@...csson.com
Cc:	netdev@...r.kernel.org, paul.gortmaker@...driver.com,
	parthasarathy.xx.bhuvaragan@...csson.com,
	richard.alpe@...csson.com, ying.xue@...driver.com,
	maloy@...jonn.com, tipc-discussion@...ts.sourceforge.net
Subject: Re: [PATCH net 1/1] tipc: eliminate risk of stalled link
 synchronization

From: Jon Maloy <jon.maloy@...csson.com>
Date: Tue, 13 Oct 2015 12:41:51 -0400

> In commit 6e498158a827 ("tipc: move link synch and failover to link aggregation level")
> we introduced a new mechanism for performing link failover and
> synchronization. We have now detected a bug in this mechanism.
> 
> During link synchronization we use the arrival of any packet on
> the tunnel link to trig a check for whether it has reached the
> synchronization point or not. This has turned out to be too
> permissive, since it may cause an arriving non-last SYNCH packet to
> end the synch state, just to see the next SYNCH packet initiate a
> new synch state with a new, higher synch point. This is not fatal,
> but should be avoided, because it may significantly extend the
> synchronization period, while at the same time we are not allowed
> to send NACKs if packets are lost. In the worst case, a low-traffic
> user may see its traffic stall until a LINK_PROTOCOL state message
> trigs the link to leave synchronization state.
> 
> At the same time, LINK_PROTOCOL packets which happen to have a (non-
> valid) sequence number lower than the tunnel link's rcv_nxt value will
> be consistently dropped, and will never be able to resolve the situation
> described above.
> 
> We fix this by exempting LINK_PROTOCOL packets from the sequence number
> check, as they should be. We also reduce (but don't completely
> eliminate) the risk of entering multiple synchronization states by only
> allowing the (logically) first SYNCH packet to initiate a synchronization
> state. This works independently of actual packet arrival order.
> 
> Fixes: commit 6e498158a827 ("tipc: move link synch and failover to link aggregation level")
> 
> Signed-off-by: Jon Maloy <jon.maloy@...csson.com>
> Acked-by: Ying Xue <ying.xue@...driver.com>

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html