Re: [PATCH] netfilter: nf_nat: Fix possible null dereference

[subashab@codeaurora.org]

> I see, but if you look nf_nat_ipv4_fn() then you can confirm that we
> always have a nat extension in place by when the iptables NAT
> targets / nft NAT expressions:
>
> nf_nat_ipv4_fn(...)
> {
>         [...]
>
>         ct = nf_ct_get(skb, &ctinfo);
>         /* Can't track?  It's not due to stress, or conntrack would
>          * have dropped it.  Hence it's the user's responsibilty to
>          * packet filter it out, or implement conntrack/NAT for that
>          * protocol. 8) --RR
>          */
>         if (!ct)
>                 return NF_ACCEPT;
>
>         /* Don't try to NAT if this packet is not conntracked */
>         if (nf_ct_is_untracked(ct))
>                 return NF_ACCEPT;
>
>         nat = nf_ct_nat_ext_add(ct);
>         if (nat == NULL)
>                 return NF_ACCEPT;
>
>         ...
>
> If we fail to create the nat extension, then this accepts the packet,
> so no chances we can reach this NULL dereference.
>
> I wonder if this is a false positive. Would you please have a closer
> look and confirm this? Thanks.
>
This report is indeed a false positive. Thanks for reviewing.