From: Guillaume Nault <gnault@redhat.com>
To: Stefano Brivio <sbrivio@redhat.com>
Cc: David Miller <davem@davemloft.net>, Julian Anastasov <ja@ssi.bg>,
Nicolas Dichtel <nicolas.dichtel@6wind.com>,
David Ahern <dsahern@gmail.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next] ipv6: Don't use dst gateway directly in ip6_confirm_neigh()
Date: Tue, 10 Sep 2019 17:03:43 +0200 [thread overview]
Message-ID: <20190910150343.GC21550@linux.home> (raw)
In-Reply-To: <938b711c35ce3fa2b6f057cc23919e897a1e5c2b.1568061608.git.sbrivio@redhat.com>
On Mon, Sep 09, 2019 at 10:44:06PM +0200, Stefano Brivio wrote:
> This is the equivalent of commit 2c6b55f45d53 ("ipv6: fix neighbour
> resolution with raw socket") for ip6_confirm_neigh(): we can send a
> packet with MSG_CONFIRM on a raw socket for a connected route, so the
> gateway would be :: here, and we should pick the next hop using
> rt6_nexthop() instead.
>
> This was found by code review and, to the best of my knowledge, doesn't
> actually fix a practical issue: the destination address from the packet
> is not considered while confirming a neighbour, as ip6_confirm_neigh()
> calls choose_neigh_daddr() without passing the packet, so there are no
> similar issues as the one fixed by said commit.
>
> A possible source of issues with the existing implementation might come
> from the fact that, if we have a cached dst, we won't consider it,
> while rt6_nexthop() takes care of that. I might just not be creative
> enough to find a practical problem here: the only way to affect this
> with cached routes is to have one coming from an ICMPv6 redirect, but
> if the next hop is a directly connected host, there should be no
> topology for which a redirect applies here, and tests with redirected
> routes show no differences for MSG_CONFIRM (and MSG_PROBE) packets on
> raw sockets destined to a directly connected host.
>
> However, directly using the dst gateway here is not consistent anymore
> with neighbour resolution, and, in general, as we want the next hop,
> using rt6_nexthop() looks like the only sane way to fetch it.
>
> Reported-by: Guillaume Nault <gnault@redhat.com>
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> ---
> net/ipv6/route.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 7a5d331cdefa..874641d4d2a1 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -227,7 +227,7 @@ static void ip6_confirm_neigh(const struct dst_entry *dst, const void *daddr)
> struct net_device *dev = dst->dev;
> struct rt6_info *rt = (struct rt6_info *)dst;
>
> - daddr = choose_neigh_daddr(&rt->rt6i_gateway, NULL, daddr);
> + daddr = choose_neigh_daddr(rt6_nexthop(rt, &in6addr_any), NULL, daddr);
> if (!daddr)
> return;
> if (dev->flags & (IFF_NOARP | IFF_LOOPBACK))
>
Acked-by: Guillaume Nault <gnault@redhat.com>
next prev parent reply other threads:[~2019-09-10 15:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-09 20:44 [PATCH net-next] ipv6: Don't use dst gateway directly in ip6_confirm_neigh() Stefano Brivio
2019-09-10 15:03 ` Guillaume Nault [this message]
2019-09-11 11:47 ` Nicolas Dichtel
2019-09-11 22:52 ` David Miller
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=20190910150343.GC21550@linux.home \
--to=gnault@redhat.com \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=ja@ssi.bg \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=sbrivio@redhat.com \
/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).