netdev - RE: [PATCH] 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:	Fri, 29 Apr 2016 11:08:10 +0000
From:	Jon Maloy <jon.maloy@...csson.com>
To:	Hamish Martin <hamish.martin@...iedtelesis.co.nz>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH] tipc: Only process unicast on intended node

Not acked. I will post an updated version of this later today to 'net'.

///jon

> -----Original Message-----
> From: Hamish Martin [mailto:hamish.martin@...iedtelesis.co.nz]
> Sent: Thursday, 28 April, 2016 21:35
> To: Jon Maloy; netdev@...r.kernel.org
> Cc: Hamish Martin
> Subject: [PATCH] tipc: Only process unicast on intended node
> 
> 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.
> 
> Signed-off-by: Hamish Martin <hamish.martin@...iedtelesis.co.nz>
> Reviewed-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
> Reviewed-by: John Thompson <john.thompson@...iedtelesis.co.nz>
> ---
>  net/tipc/node.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/net/tipc/node.c b/net/tipc/node.c
> index ace178fd3850..e5dda495d4b6 100644
> --- a/net/tipc/node.c
> +++ b/net/tipc/node.c
> @@ -1460,6 +1460,11 @@ void tipc_rcv(struct net *net, struct sk_buff *skb,
> struct tipc_bearer *b)
>  			return tipc_node_bc_rcv(net, skb, bearer_id);
>  	}
> 
> +	/* Discard unicast link messages destined for another node */
> +	if (unlikely(!msg_short(hdr) &&
> +		     (msg_destnode(hdr) != tipc_own_addr(net))))
> +		goto discard;
> +
>  	/* Locate neighboring node that sent packet */
>  	n = tipc_node_find(net, msg_prevnode(hdr));
>  	if (unlikely(!n))
> --
> 2.8.1