netdev - Re: [PATCH net v2 1/1] tipc: only process unicast on intended node

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:	Sun, 01 May 2016 21:04:00 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	jon.maloy@...csson.com
Cc:	netdev@...r.kernel.org, paul.gortmaker@...driver.com,
	parthasarathy.bhuvaragan@...csson.com, richard.alpe@...csson.com,
	ying.xue@...driver.com, maloy@...jonn.com,
	tipc-discussion@...ts.sourceforge.net,
	hamish.martin@...iedtelesis.co.nz
Subject: Re: [PATCH net v2 1/1] tipc: only process unicast on intended node

From: Jon Maloy <jon.maloy@...csson.com>
Date: Fri, 29 Apr 2016 10:40:24 -0400

> From: Hamish Martin <hamish.martin@...iedtelesis.co.nz>
> 
> We have observed complete lock up of broadcast-link transmission due to
> unacknowledged packets never being removed from the 'transmq' queue. This
> is traced to nodes having their ack field set beyond the sequence number
> of packets that have actually been transmitted to them.
> Consider an example where node 1 has sent 10 packets to node 2 on a
> link and node 3 has sent 20 packets to node 2 on another link. We
> see examples of an ack from node 2 destined for node 3 being treated as
> an ack from node 2 at node 1. This leads to the ack on the node 1 to node
> 2 link being increased to 20 even though we have only sent 10 packets.
> When node 1 does get around to sending further packets, none of the
> packets with sequence numbers less than 21 are actually removed from the
> transmq.
> To resolve this we reinstate some code lost in commit d999297c3dbb ("tipc:
> reduce locking scope during packet reception") which ensures that only
> messages destined for the receiving node are processed by that node. This
> prevents the sequence numbers from getting out of sync and resolves the
> packet leakage, thereby resolving the broadcast-link transmission
> lock-ups we observed.
> 
> While we are aware that this change only patches over a root problem that
> we still haven't identified, this is a sanity test that it is always
> legitimate to do. It will remain in the code even after we identify and
> fix the real problem.
> 
> Reviewed-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
> Reviewed-by: John Thompson <john.thompson@...iedtelesis.co.nz>
> Signed-off-by: Hamish Martin <hamish.martin@...iedtelesis.co.nz>
> Signed-off-by: Jon Maloy <jon.maloy@...csson.com>

Applied.