tipc: eliminate risk of finding to-be-deleted node instance
authorJon Paul Maloy <jon.maloy@ericsson.com>
Wed, 24 Feb 2016 16:00:19 +0000 (11:00 -0500)
committerDavid S. Miller <davem@davemloft.net>
Thu, 25 Feb 2016 22:04:48 +0000 (17:04 -0500)
commitb170997acedc6c11ed2ec07b8d415601e65bb452
treeb0759cbe4ceec6d799d8830fd03f3fd5e357a271
parent3da7611f4285e0434dff62bcabb8b5bfdae5915f
tipc: eliminate risk of finding to-be-deleted node instance

Although we have never seen it happen, we have identified the
following problematic scenario when nodes are stopped and deleted:

CPU0:                            CPU1:

tipc_node_xxx()                                   //ref == 1
   tipc_node_put()                                //ref -> 0
                                 tipc_node_find() // node still in table
       tipc_node_delete()
         list_del_rcu(n. list)
                                 tipc_node_get()  //ref -> 1, bad
         kfree_rcu()

                                 tipc_node_put() //ref to 0 again.
                                 kfree_rcu()     // BOOM!

We fix this by introducing use of the conditional kref_get_if_not_zero()
instead of kref_get() in the function tipc_node_find(). This eliminates
any risk of post-mortem access.

Reported-by: Zhijiang Hu <huzhijiang@gmail.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/tipc/node.c