Re: [PATCH] net: xfrm: fix a race condition during allocing spi
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2020-10-21 07:12:34
Also in:
linux-mediatek, lkml, netdev
On Tue, Oct 20, 2020 at 04:18:00PM +0800, Zhuoliang Zhang wrote:
From: zhuoliang zhang <redacted>
we found that the following race condition exists in
xfrm_alloc_userspi flow:
user thread state_hash_work thread
---- ----
xfrm_alloc_userspi()
__find_acq_core()
/*alloc new xfrm_state:x*/
xfrm_state_alloc()
/*schedule state_hash_work thread*/
xfrm_hash_grow_check() xfrm_hash_resize()
xfrm_alloc_spi /*hold lock*/
x->id.spi = htonl(spi) spin_lock_bh(&net->xfrm.xfrm_state_lock)
/*waiting lock release*/ xfrm_hash_transfer()
spin_lock_bh(&net->xfrm.xfrm_state_lock) /*add x into hlist:net->xfrm.state_byspi*/
hlist_add_head_rcu(&x->byspi)
spin_unlock_bh(&net->xfrm.xfrm_state_lock)
/*add x into hlist:net->xfrm.state_byspi 2 times*/
hlist_add_head_rcu(&x->byspi)
So the same xfrm_stame (x) is added into the same list_hash
(net->xfrm.state_byspi)2 times that makes the list_hash become
a inifite loop.Your explanation makes no sense. Prior to obtaining the spin lock on the LHS, the state x hasn't been added to thte table yet. So how can the RHS be transferring it? Cheers, -- Email: Herbert Xu [off-list ref] Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel