netdev - Re: [RFC PATCH ipsec] xfrm: use the right dev to fill xdst

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:	Fri, 5 Apr 2013 11:46:29 +0200
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
Cc:	herbert@...dor.apana.org.au, davem@...emloft.net,
	netdev@...r.kernel.org, dbaluta@...acom.com
Subject: Re: [RFC PATCH ipsec] xfrm: use the right dev to fill xdst

On Thu, Apr 04, 2013 at 05:12:42PM +0200, Nicolas Dichtel wrote:
> Commit bc8e4b954e46 (xfrm6: ensure to use the same dev when building a bundle)
> broke IPsec for IPv4 over IPv6 tunnels (because dev points to an IPv4 only
> interface, hence in6_dev_get(dev) returns NULL.

Can you give some informations on how to reproduce this? I'm running
interfamily tunnels on our testing environment and it seems to
work fine.

> 
> After looking again into commit 25ee3286dcbc ([IPSEC]: Merge common code into
> xfrm_bundle_create), it seems that previously we were using dev from the route,
> for both IPv4 and IPv6.

I think this was the right way. We need to attach the dev from the
corresponding route to the xdst.

> 
> In fact, xfrm_fill_dst() is called during a loop on chained dst, but dev points
> always to the same device.

The way we do it now can be problematic for tunnel in tunnel scenarios too.
We assign the dev from the first tunnel route to all the bundle entries,
this looks really wrong.

I think your patch is correct, but I want understand the breaking 
scenario first.

Thanks!

--
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