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

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]

Message-Id: <20070914.134252.112612041.davem@davemloft.net>
Date:	Fri, 14 Sep 2007 13:42:52 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	joakim.koskela@...t.fi
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-2.6.23-rc5] ipsec interfamily route handling fix

From: Joakim Koskela <joakim.koskela@...t.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@...il.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?
-
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