From: Pablo Neira Ayuso <pablo@netfilter.org>
To: subashab@codeaurora.org
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] netfilter: nf_nat: Fix possible null dereference
Date: Mon, 13 Jul 2015 17:50:03 +0200 [thread overview]
Message-ID: <20150713155003.GA7062@salvia> (raw)
In-Reply-To: <4acf7f20a629dd133bf5924886c0c4d0.squirrel@www.codeaurora.org>
On Thu, Jul 09, 2015 at 11:16:05PM -0000, subashab@codeaurora.org wrote:
> > 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.
> >
>
> Sure, here is the report
>
> - In nf_nat_masquerade_ipv4.c line 40, 'nat' is assigned the value from
> function 'nfct_nat'
> - In nf_nat.h line 58, '__nf_ct_ext_find( (ct), (NF_CT_EXT_NAT) )' is
> assigned the return value from function '__nf_ct_ext_find'.
> - In nf_conntrack_extend.h line 68, '__nf_ct_ext_find' explicitly returns
> a NULL value.
>
> - As a result, pointer 'nat' returned from call to function 'nfct_nat' at
> line 40 may be NULL and may be dereferenced at line 59 'nat->masq_index =
> out->ifindex;'
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.
next prev parent reply other threads:[~2015-07-13 15:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-09 1:23 [PATCH] netfilter: nf_nat: Fix possible null dereference subashab
2015-07-09 22:24 ` Pablo Neira Ayuso
2015-07-09 23:16 ` subashab
2015-07-13 15:50 ` Pablo Neira Ayuso [this message]
2015-07-15 1:10 ` subashab
-- strict thread matches above, loose matches on Subject: below --
2015-06-29 17:40 subashab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150713155003.GA7062@salvia \
--to=pablo@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=subashab@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.