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  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, 14 Sep 2007 13:42:52 -0700 (PDT)
From:	David Miller <>
Subject: Re: [PATCH net-2.6.23-rc5] ipsec interfamily route handling fix

From: Joakim Koskela <>
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 <>

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
More majordomo info at

Powered by blists - more mailing lists