netdev - Re: [PATCH net-next] net: Fix vti use case with oif in dst lookups for IPv6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 20 Oct 2015 21:31:28 +0900
From:	Hajime Tazaki <thehajime@...il.com>
To:	dsa@...ulusnetworks.com
Cc:	steffen.klassert@...unet.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: Fix vti use case with oif in dst lookups for IPv6


Hello David,

sorry for the delay.

At Sun, 11 Oct 2015 12:01:30 -0600,
David Ahern wrote:
> 
> On 10/11/15 8:24 AM, Hajime Tazaki wrote:
> >
> > I've faced this issue since the following patch was applied.
> >
> > commit 741a11d9e4103a8e1c590ef1280143fe654e4e33
> > Author: David Ahern <dsa@...ulusnetworks.com>
> > Date:   Mon Sep 28 10:12:13 2015 -0700
> >
> >      net: ipv6: Add RT6_LOOKUP_F_IFACE flag if oif is set
> >
> > I still couldn't spot which part (other than my posted call
> > graph) is broken and am not sure whether the xfrm change
> > affects or not (which I need to check the mip6 code again).
> 
> Ok, this is a separate problem from what Steffen is hitting.

agree.

> >
> >> Can you apply this patch, and then run:
> >>
> >> perf record -e fib6:* -a -g
> >> perf script
> >
> > I'm using libos environment right now, so the perf trace
> > can't be used as it is.
> 
> ok.
> 
> Some path in raw6_sendmsg is setting fl6.flowi6_oif. Can you instrument it?

yes, this sendmsg uses non-zero flowi6_oif.


the conditions are

- sendmsg () with INET6/RAW socket (with IPPROTO_MH)
- ip6_pktinfo.ipi6_addr (fl6.saddr) and ipi6_oif
  (fl6.flowi6_oif) are non-NULL.
=> ipi6_addr (fl6.saddr) is not the IP address of oif, but
    another interfaces (home address of mip6)
- fib6_lookup() (in ip6_pol_route()) gives ip6_null_entry

if RT6_LOOKUP_F_IFACE isn't set at ip6_route_output, it
can look for a proper dst_entry of default route
if not, it gives EINVAL.

I'm sure that this is not the right fix for this issue, but
the following patch solves my situation.

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index df24cff4a0cb..02e86989b3cb 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1079,6 +1079,12 @@ redo_rt6_select:
                fn = fib6_backtrack(fn, &fl6->saddr);
                if (fn) 
                        goto redo_rt6_select;
+               else if (strict & RT6_LOOKUP_F_IFACE) {
+                       /* also consider non-interface route */
+                       strict &= ~RT6_LOOKUP_F_IFACE;
+                       fn = saved_fn;
+                       goto redo_rt6_select;
+               }
                else if (strict & RT6_LOOKUP_F_REACHABLE) {
                        /* also consider unreachable route */
                        strict &= ~RT6_LOOKUP_F_REACHABLE;

I'm trying to create a minimum reproducible code and spot
the issue but not get it yet. let me know if you find any
good idea.

-- Hajime
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html