netdev - Re: [net 1/1] tipc: eliminate message disordering during binding table update

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 22 Oct 2018 19:29:42 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     jon.maloy@...csson.com
Cc:     netdev@...r.kernel.org, gordan.mihaljevic@...tech.com.au,
        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: eliminate message disordering during binding
 table update

From: Jon Maloy <jon.maloy@...csson.com>
Date: Fri, 19 Oct 2018 19:55:40 +0200

> We have seen the following race scenario:
> 1) named_distribute() builds a "bulk" message, containing a PUBLISH
>    item for a certain publication. This is based on the contents of
>    the binding tables's 'cluster_scope' list.
> 2) tipc_named_withdraw() removes the same publication from the list,
>    bulds a WITHDRAW message and distributes it to all cluster nodes.
> 3) tipc_named_node_up(), which was calling named_distribute(), sends
>    out the bulk message built under 1)
> 4) The WITHDRAW message arrives at the just detected node, finds
>    no corresponding publication, and is dropped.
> 5) The PUBLISH item arrives at the same node, is added to its binding
>    table, and remains there forever.
> 
> This arrival disordering was earlier taken care of by the backlog queue,
> originally added for a different purpose, which was removed in the
> commit referred to below, but we now need a different solution.
> In this commit, we replace the rcu lock protecting the 'cluster_scope'
> list with a regular RW lock which comprises even the sending of the
> bulk message. This both guarantees both the list integrity and the
> message sending order. We will later add a commit which cleans up
> this code further.
> 
> Note that this commit needs recently added commit d3092b2efca1 ("tipc:
> fix unsafe rcu locking when accessing publication list") to apply
> cleanly.
> 
> Fixes: 37922ea4a310 ("tipc: permit overlapping service ranges in name table")
> Reported-by: Tuong Lien Tong <tuong.t.lien@...tech.com.au>
> Acked-by: Ying Xue <ying.xue@...driver.com>
> Signed-off-by: Jon Maloy <jon.maloy@...csson.com>

Applied.