From: linmiaohe <linmiaohe@huawei.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: "kadlec@blackhole.kfki.hu" <kadlec@blackhole.kfki.hu>,
"fw@strlen.de" <fw@strlen.de>,
"davem@davemloft.net" <davem@davemloft.net>,
"kuznet@ms2.inr.ac.ru" <kuznet@ms2.inr.ac.ru>,
"yoshfuji@linux-ipv6.org" <yoshfuji@linux-ipv6.org>,
"netfilter-devel@vger.kernel.org"
<netfilter-devel@vger.kernel.org>,
"coreteam@netfilter.org" <coreteam@netfilter.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dsahern@gmail.com" <dsahern@gmail.com>,
Mingfangsen <mingfangsen@huawei.com>
Subject: Re: [PATCH v3] net: netfilter: Fix rpfilter dropping vrf packets by mistake
Date: Tue, 25 Jun 2019 08:51:12 +0000 [thread overview]
Message-ID: <badbfdd3c6474994a481375dad2a51f3@huawei.com> (raw)
On Wed, Jun 19, 2019 at 09:49:04AM +0000, linmiaohe wrote:
>
> On 2019/6/18 23:58, Pablo Neira Ayuso wrote:
> > On Thu, Apr 25, 2019 at 09:43:53PM +0800, linmiaohe wrote:
> >> From: Miaohe Lin <linmiaohe@huawei.com>
> >>
> >> When firewalld is enabled with ipv4/ipv6 rpfilter, vrf
> >> ipv4/ipv6 packets will be dropped because in device is vrf but out
> >> device is an enslaved device. So failed with the check of the
> >> rpfilter.
> >>
> >> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> >> ---
> >> --- a/net/ipv4/netfilter/ipt_rpfilter.c
> >> +++ b/net/ipv4/netfilter/ipt_rpfilter.c
> >> @@ -81,6 +81,7 @@ static bool rpfilter_mt(const struct sk_buff *skb, struct xt_action_param *par)
> >> flow.flowi4_mark = info->flags & XT_RPFILTER_VALID_MARK ? skb->mark : 0;
> >> flow.flowi4_tos = RT_TOS(iph->tos);
> >> flow.flowi4_scope = RT_SCOPE_UNIVERSE;
> >> + flow.flowi4_oif = l3mdev_master_ifindex_rcu(xt_in(par));
> >>
> >> return rpfilter_lookup_reverse(xt_net(par), &flow, xt_in(par),
> >> --- a/net/ipv6/netfilter/ip6t_rpfilter.c
> >> +++ b/net/ipv6/netfilter/ip6t_rpfilter.c
> >> @@ -58,7 +58,9 @@ static bool rpfilter_lookup_reverse6(struct net *net, const struct sk_buff *skb,
> >> if (rpfilter_addr_linklocal(&iph->saddr)) {
> >> lookup_flags |= RT6_LOOKUP_F_IFACE;
> >> fl6.flowi6_oif = dev->ifindex;
> >> - } else if ((flags & XT_RPFILTER_LOOSE) == 0)
> >> + } else if (((flags & XT_RPFILTER_LOOSE) == 0) ||
> >> + (netif_is_l3_master(dev)) ||
> >> + (netif_is_l3_slave(dev)))
> >> fl6.flowi6_oif = dev->ifindex;
> >>
> >> rt = (void *)ip6_route_lookup(net, &fl6, skb, lookup_flags); @@
> >> -73,6 +75,12 @@ static bool rpfilter_lookup_reverse6(struct net *net, const struct sk_buff *skb,
> >> goto out;
> >> }
> >>
> >> + if (netif_is_l3_master(dev)) {
> >> + dev = dev_get_by_index_rcu(dev_net(dev), IP6CB(skb)->iif);
> >> + if (!dev)
> >> + goto out;
> >> + }
> >
> > So, for the l3 device cases this makes:
> >
> > #1 ip6_route_lookup() to fetch the route, using the device in xt_in()
> > (the _LOOSE flag is ignored for the l3 device case).
> >
> > #2 If this is a l3dev master, then you make a global lookup for the
> > device using IP6CB(skb)->iif.
> >
> > #3 You check if route matches with the device, using the new device
> > from the lookup:
> >
> > if (rt->rt6i_idev->dev == dev ...
> >
> > If there is no other way to fix this, OK, that's fair enough.
> >
> > Still this fix looks a bit tricky to me.
> >
> > And this assymmetric between the IPv4 and IPv6 codebase looks rare.
> >
> > Probably someone can explain me this in more detail? I'd appreciate.
> >
> > Thanks!
> >
> Thanks for explaining.
>
> Something must be wrong in all these helper function logic because this new code logic is hard to follow for the IPv6 chunk...
>
> Can you explore a more readable fix?
>
> So I'm not inclined to quickly take this patch.
>
> Thanks.
Thanks, I will try a more readable fix.
next reply other threads:[~2019-06-25 8:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-25 8:51 linmiaohe [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-06-19 9:49 [PATCH v3] net: netfilter: Fix rpfilter dropping vrf packets by mistake linmiaohe
2019-06-25 8:17 ` Pablo Neira Ayuso
2019-04-25 13:43 linmiaohe
2019-04-26 16:06 ` David Ahern
2019-05-13 9:42 ` Pablo Neira Ayuso
2019-05-13 13:25 ` linmiaohe
2019-06-18 15:57 ` Pablo Neira Ayuso
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=badbfdd3c6474994a481375dad2a51f3@huawei.com \
--to=linmiaohe@huawei.com \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=fw@strlen.de \
--cc=kadlec@blackhole.kfki.hu \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mingfangsen@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=yoshfuji@linux-ipv6.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).