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
| ||
|
Message-ID: <87hblss92x.fsf@small.ssi.corp> Date: Fri, 28 May 2010 10:51:18 +0200 From: arno@...isbad.org (Arnaud Ebalard) To: Scott C Otto <otts@...atel-lucent.com> Cc: Brian Haley <brian.haley@...com>, David Miller <davem@...emloft.net>, YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@...ux-ipv6.org>, Jiri Olsa <jolsa@...hat.com>, netdev@...r.kernel.org Subject: Re: [REGRESSION,BISECTED] MIPv6 support broken by f4f914b58019f0 Hi, Scott C Otto <otts@...atel-lucent.com> writes: > All, > Thanks for looking into this. > > The behavior of SO_BINDTODEVICE, certainly with IPV4, is to identify a specific > interface to use for sending/receiving AF_INET packets upon. And that's how it > has behaved with IPV4. Tools like ping, traceroute (and ping6, traceroute6) > make use of it with the -i (interface) options. > > We ran into this issue when updating an IPV4 application to IPV6. The report > provided one example of the issue. > > The original change was based on the semantics of flowi.oif used in IPV4. There > flowi.oif (as it is with IPV6 as well) is also set to sk->sk_bound_dev_if when > using ip_route_connect() and routing simply took a non-zero oif to enforce an > interface. Looking at IPV4 tunneling, flowi.oif is set the same way from > tunnel's parms.link as with IPV6 so would follow those semantics as well. > > Obviously, with IPV6, the semantics of flowi.oif are different and perhaps even > vary with the users of IPV6. > > If that variability is desired, the proposed change from Brian (using > sk->sk_bound_dev_if) would be an equivalent means of supporting SO_BINDTODEVICE > while limiting the impact. ok. Thanks for the feedback. Can you comment on what is below? >> The below might actually be what was actually intended, triggering >> on what the user forced, rather than assuming all callers require >> strict behavior. >> >> -Brian >> >> >> diff --git a/net/ipv6/route.c b/net/ipv6/route.c >> index 294cbe8..252d761 100644 >> --- a/net/ipv6/route.c >> +++ b/net/ipv6/route.c >> @@ -814,7 +814,7 @@ struct dst_entry * ip6_route_output(struct net *net, struct sock *sk, >> { >> int flags = 0; >> >> - if (fl->oif || rt6_need_strict(&fl->fl6_dst)) >> + if ((sk && sk->sk_bound_dev_if) || rt6_need_strict(&fl->fl6_dst)) >> flags |= RT6_LOOKUP_F_IFACE; >> >> if (!ipv6_addr_any(&fl->fl6_src)) Brian, I tested the patch on my Mobile Node: it fixes the regression. I also updated the kernel on my Home Agent to a 2.6.34 with that fix and everything works as expected. *For that aspect* and fwiw, you get my Tested-by: Arnaud Ebalard <arno@...isbad.org> For the SO_BINDTODEVICE aspect, I don't have code at hand to test if the fix works as expected. We should also double check that this will not break other paths which use the sk->sk_bound_dev_if with a different semantic: $ grep -R sk_bound_dev_if net/ | wc -l 125 $ grep -R 'sk_bound_dev_if = ' net/ net/ieee802154/raw.c: sk->sk_bound_dev_if = dev->ifindex; net/core/sock.c: sk->sk_bound_dev_if = index; net/ipv6/datagram.c: sk->sk_bound_dev_if = usin->sin6_scope_id; net/ipv6/datagram.c: sk->sk_bound_dev_if = np->mcast_oif; net/ipv6/af_inet6.c: sk->sk_bound_dev_if = addr->sin6_scope_id; net/ipv6/tcp_ipv6.c: sk->sk_bound_dev_if = usin->sin6_scope_id; net/ipv6/tcp_ipv6.c: newsk->sk_bound_dev_if = treq->iif; net/ipv6/raw.c: sk->sk_bound_dev_if = addr->sin6_scope_id; net/sctp/socket.c: newsk->sk_bound_dev_if = sk->sk_bound_dev_if; net/ipv4/ip_output.c: sk->sk_bound_dev_if = arg->bound_dev_if; net/ipv4/udp.c: sk->sk_bound_dev_if = 0; net/dccp/ipv6.c: newsk->sk_bound_dev_if = ireq6->iif; net/dccp/ipv6.c: sk->sk_bound_dev_if = usin->sin6_scope_id; Cheers, a+ -- 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
Powered by blists - more mailing lists