Check net->nfnl for NULL in ctnetlink_conntrack_event to, avoid Oops on container destroy

Patrick,

I received this patch from a developer that uses lxc and network name spaces. I don't know the locking semantics well enough for CT to judge whether this fix is sufficient. Bug info can be found at http://bugs.launchpad.net/bugs/843892 . See comment #7 for his analysis.

rtg

Tim Gardner [email protected]

From: Alex Bligh <[email protected]>
Date: Sat, 10 Sep 2011 13:29:12 +0100
Subject: [PATCH] Check net->nfnl for NULL in ctnetlink_conntrack_event to
avoid Oops on container destroy

---
 net/netfilter/nf_conntrack_netlink.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

index 482e90c..0790d0a 100644
@@ -570,6 +570,11 @@ ctnetlink_conntrack_event(unsigned int events, struct nf_ct_event *item)
 		return 0;
 
 	net = nf_ct_net(ct);
+
+	/* container deinit, netlink may have died before death_by_timeout */
+	if (!net->nfnl)
+		return 0;
+
 	if (!item->report && !nfnetlink_has_listeners(net, group))
 		return 0;
 

1.7.5.4

Never mind. Looks like Alex already sent this patch on Sept 10 with the subject 'Fix repeatable Oops on container destroy with conntrack'.

rtg

Tim Gardner [email protected]

Hello,

We found same problems triggered by IPVS during
subsys cleanup:

http://marc.info/?l=netfilter-devel&m=130765388528399&w=2

It is a general problem for modules that register
callbacks to the netfilter core. nfnetlink is such example with a mix of global (ctnl_notifier) and per-net (nfnetlink_net_ops) registrations. During net cleanup the module must be prepared to be called by core because the core cleanup happens later.

So, may be rcu_dereference under rcu lock is needed for
some functions (nfnetlink_has_listeners, nfnetlink_send) but such changes should be audited by nfnetlink developers. Using rcu_assign_pointer for net->nfnl without corresponding rcu_dereference looks like a problem.

Regards

--
Julian Anastasov <[email protected]>

We're still discussing a better solution for it.