| Message ID | 20170831114524.7511-1-fw@strlen.de |
|---|---|
| State | Accepted |
| Delegated to: | Pablo Neira |
| Headers | show |
| Series | [nf] netfilter: nf_nat: don't bug when mapping already exists | expand |
On Thu, Aug 31, 2017 at 01:45:24PM +0200, Florian Westphal wrote: > It seems preferrable to limp along if we have a conflicting mapping, > its certainly better than a BUG(). Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c index b1d3740ae36a..c1587e8427ef 100644 --- a/net/netfilter/nf_nat_core.c +++ b/net/netfilter/nf_nat_core.c @@ -416,7 +416,8 @@ nf_nat_setup_info(struct nf_conn *ct, NF_CT_ASSERT(maniptype == NF_NAT_MANIP_SRC || maniptype == NF_NAT_MANIP_DST); - BUG_ON(nf_nat_initialized(ct, maniptype)); + if (WARN_ON(nf_nat_initialized(ct, maniptype))) + return NF_DROP; /* What we've got will look like inverse of reply. Normally * this is what is in the conntrack, except for prior
It seems preferrable to limp along if we have a conflicting mapping, its certainly better than a BUG(). Signed-off-by: Florian Westphal <fw@strlen.de> --- This can be triggered with nfqueue and bridge netfilter. So far we found no good way to fix this problem (bridge netfilter violates conntrack assumption wrt. ownership of ct by single cpu).