Hi Pablo, On Fri, Mar 3, 2017 at 5:30 PM, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > On Fri, Mar 03, 2017 at 09:58:52AM +0800, fgao@xxxxxxxxxx wrote: >> From: Gao Feng <fgao@xxxxxxxxxx> >> >> When memory is exhausted, nf_ct_nat_ext_add may return NULL. Then >> nf_nat_ipv4_fn and nf_nat_ipv6_fn would return NF_ACCEPT in this >> case. >> So we need add the NULL check when invoke nfct_nat in these two >> functions. >> >> Signed-off-by: Gao Feng <fgao@xxxxxxxxxx> >> --- >> net/ipv4/netfilter/nf_nat_masquerade_ipv4.c | 2 ++ >> net/ipv6/netfilter/nf_nat_masquerade_ipv6.c | 6 +++++- >> 2 files changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c >> index ea91058..353ca0c 100644 >> --- a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c >> +++ b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c >> @@ -38,6 +38,8 @@ >> >> ct = nf_ct_get(skb, &ctinfo); >> nat = nfct_nat(ct); >> + if (!nat) >> + return NF_ACCEPT; > > The masquerade target is only called from the nat table. If you look > at nf_nat_ipv4_fn(), that is called whenever the packet enters a nat > table, you can indeed check that nfct_nat() must be already there by > when we call masquerade. > > So this is entirely unnecessary. Thanks your answer. I should find the masquerade only is called nat table. And the nf_nat_ipv4_fn function should make sure the nat is valid . Thanks again. Regards Feng -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
