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
| ||
|
Date: Wed, 10 Apr 2013 14:39:39 +0300 From: Daniel Baluta <dbaluta@...acom.com> To: Steffen Klassert <steffen.klassert@...unet.com> CC: David Miller <davem@...emloft.net>, <nicolas.dichtel@...nd.com>, <herbert@...dor.apana.org.au>, <netdev@...r.kernel.org> Subject: Re: [RFC PATCH ipsec] xfrm: use the right dev to fill xdst On 04/10/2013 02:29 PM, Steffen Klassert wrote: > On Tue, Apr 09, 2013 at 09:18:33PM +0300, Daniel Baluta wrote: >> On Tue, Apr 9, 2013 at 8:33 PM, David Miller<davem@...emloft.net> wrote: >>> From: Daniel Baluta<daniel.baluta@...il.com> >>> Date: Tue, 9 Apr 2013 20:31:30 +0300 >>> >>>> As I mentioned earlier in this thread we are using some custom >>>> kernel modules that create the interfaces. >>>> >>>> It's likely that these interfaces, for memory saving purposes, to >>>> skip attaching ipv6 device information. >>> So this is not an upstream bug. >> Correct. >> >> With conditions mentioned by Steffen, in upstream, each net_device >> has an in6_device assigned so we won't hit the problem. >> > We have an in6_device assigned in almost all of the cases, but I doubt > it is always the right one. > > Let's say we want to tunnel ipv6 over ipv4. We do an ipv6 route lookup > that returns a route with output device, say eth0. With that route, > we do an IPsec route lookup and we get an ipv4 tunnel route with output > device eth1. > > When we create the xfrm_dst in xfrm_bundle_create(), we copy the > informations from the original ipv6 route, because we pass the new > allocated IPsec route back to the ipv6 layer. But the device is taken > from the ipv4 tunnel route (eth1 instead of eth0), so we pass a > dst_entry with a ipv4 device assigned to the ipv6 layer. > > For that reason, xfrm6_fill_dst() complains about a NULL in6_device, > when the mtu of the ipv4 device (passed to xfrm6_fill_dst()) is > below IPV6_MIN_MTU. > > I think there is to fix something, but this needs some more research > before we can do anything about that. > I will try to further look into this. If you have any scripts that can ease IPSec tunnels setup please do share. thanks, daniel. -- 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