netdev - Re: [net-next 1/1] tipc: fix race condition at topology server receive

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: <20180116.144254.1952039888762980221.davem@davemloft.net>
Date:   Tue, 16 Jan 2018 14:42:54 -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-next 1/1] tipc: fix race condition at topology server
 receive

From: Jon Maloy <jon.maloy@...csson.com>
Date: Mon, 15 Jan 2018 17:56:28 +0100

> We have identified a race condition during reception of socket
> events and messages in the topology server.
> 
> - The function tipc_close_conn() is releasing the corresponding
>   struct tipc_subscriber instance without considering that there
>   may still be items in the receive work queue. When those are
>   scheduled, in the function tipc_receive_from_work(), they are
>   using the subscriber pointer stored in struct tipc_conn, without
>   first checking if this is valid or not. This will sometimes
>   lead to crashes, as the next call of tipc_conn_recvmsg() will
>   access the now deleted item.
>   We fix this by making the usage of this pointer conditional on
>   whether the connection is active or not. I.e., we check the condition
>   test_bit(CF_CONNECTED) before making the call tipc_conn_recvmsg().
> 
> - Since the two functions may be running on different cores, the
>   condition test described above is not enough. tipc_close_conn()
>   may come in between and delete the subscriber item after the condition
>   test is done, but before tipc_conn_recv_msg() is finished. This
>   happens less frequently than the problem described above, but leads
>   to the same symptoms.
> 
>   We fix this by using the existing sk_callback_lock for mutual
>   exclusion in the two functions. In addition, we have to move
>   a call to tipc_conn_terminate() outside the mentioned lock to
>   avoid deadlock.
> 
> Acked-by: Ying Xue <ying.xue@...driver.com>
> Signed-off-by: Jon Maloy <jon.maloy@...csson.com>

Applied, thanks Jon.