> 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.
--
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
