[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20160225.170633.2220739017957131099.davem@davemloft.net>
Date: Thu, 25 Feb 2016 17:06:33 -0500 (EST)
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
Subject: Re: [PATCH net-next 1/1] tipc: eliminate risk of finding
to-be-deleted node instance
From: Jon Maloy <jon.maloy@...csson.com>
Date: Wed, 24 Feb 2016 11:00:19 -0500
> 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@...il.com>
> Acked-by: Ying Xue <ying.xue@...driver.com>
> Signed-off-by: Jon Maloy <jon.maloy@...csson.com>
Applied.
Powered by blists - more mailing lists