Re: [PATCH net-2.6.23-rc5] ipsec interfamily route handling fix

[David Miller <davem@davemloft.net>]

From: Joakim Koskela <joakim.koskela@hiit.fi>
Date: Thu, 6 Sep 2007 19:00:10 +0300

> This patch addresses a couple of issues related to interfamily ipsec
> modes. The problem is that the structure of the routing info changes
> with the family during the __xfrmX_bundle_create, which hasn't been
> taken properly into account. Seems that by coincidence it hasn't
> caused problems on 32bit platforms, but crashes for example on x86_64
> in 6-4 around line 209 of xfrm6_policy.c as rt doesn't point to a
> rt6_info anymore, but actually a struct rtable. With 64bit pointers,
> the rt->rt6i_node pointer seems to hit something usually not null in
> the rtable that rt now points to, making it go for the path_cookie
> assignment and subsequently crashing.
> 
> Tested on both 32/64bit with all four (44/46/64/66) combinations of
> transformation. I'm still a bit worried about how for example nested
> transformations work with all of this and would appreciate if someone
> more familiar with the details of these structs could comment.
> 
> Signed-off-by: Joakim Koskela <jookos@gmail.com>

Since nobody else found time to review this, I did :-)

It's line wrapped so doesn't apply cleanly, but it has technical
issues too.

It sets encap_type in the inner loop, but what if we find multiple
entries some ipv4 and some ipv6?  This logic can't be right.

Instead, we need to treat these objects on an individual basis, I
think, and that requires a bit more changes.

These tunnel handling code blocks are getting messy, perhaps it's
time for a little bit of indirection based upon AF type?