On Thu, Jul 09, 2015 at 01:23:58AM -0000, subashab@xxxxxxxxxxxxxx wrote:
> Fix an issue where __nf_ct_ext_find() could return null to nat in
> nf_nat_masquerade_ipv4() and could be dereferenced.
>
> This was detected by static analysis software.
>
> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@xxxxxxxxxxxxxx>
> ---
> net/ipv4/netfilter/nf_nat_masquerade_ipv4.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
> b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
> index c6eb421..4be5d70 100644
> --- a/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
> +++ b/net/ipv4/netfilter/nf_nat_masquerade_ipv4.c
> @@ -38,6 +38,8 @@ nf_nat_masquerade_ipv4(struct sk_buff *skb, unsigned int
> hooknum,
>
> ct = nf_ct_get(skb, &ctinfo);
> nat = nfct_nat(ct);
> + if (!nat)
> + return NF_DROP;
This function is called from nf_nat_ipv4_fn(), see do_chain().
And we're accepting the packet with no NAT mangling if we fail to add
the extension:
nat = nf_ct_nat_ext_add(ct);
if (nat == NULL)
return NF_ACCEPT;
Can you provide more information on what your static analysis software
reports? Thanks.
--
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
