On Mon, Apr 09, 2018 at 10:20:18AM +0300, Simon Horman wrote: > On Sat, Apr 07, 2018 at 03:50:47PM +0300, Julian Anastasov wrote: > > syzkaller reports for wrong rtnl_lock usage in sync code  and  > > > > We have 2 problems in start_sync_thread if error path is > > taken, eg. on memory allocation error or failure to configure > > sockets for mcast group or addr/port binding: > > > > 1. recursive locking: holding rtnl_lock while calling sock_release > > which in turn calls again rtnl_lock in ip_mc_drop_socket to leave > > the mcast group, as noticed by Florian Westphal. Additionally, > > sock_release can not be called while holding sync_mutex (ABBA > > deadlock). > > > > 2. task hung: holding rtnl_lock while calling kthread_stop to > > stop the running kthreads. As the kthreads do the same to leave > > the mcast group (sock_release -> ip_mc_drop_socket -> rtnl_lock) > > they hang. > > > > Fix the problems by calling rtnl_unlock early in the error path, > > now sock_release is called after unlocking both mutexes. > > > > Problem 3 (task hung reported by syzkaller ) is variant of > > problem 2: use _trylock to prevent one user to call rtnl_lock and > > then while waiting for sync_mutex to block kthreads that execute > > sock_release when they are stopped by stop_sync_thread. > > ... > > > Reported-and-tested-by: > > syzbot+a46d6abf9d56b1365...@syzkaller.appspotmail.com > > Reported-and-tested-by: > > syzbot+5fe074c01b2032ce9...@syzkaller.appspotmail.com > > Fixes: e0b26cc997d5 ("ipvs: call rtnl_lock early") > > Signed-off-by: Julian Anastasov <j...@ssi.bg> > > Signed-off-by: Simon Horman <ho...@verge.net.au> > > Pablo, could you take this directly into nf and then onwards to net?
Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html