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] [day] [month] [year] [list]

Message-Id: <200710111153.45530.joakim.koskela@hiit.fi>
Date:	Thu, 11 Oct 2007 11:53:45 +0300
From:	Joakim Koskela <joakim.koskela@...t.fi>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-2.6.23-rc5] ipsec interfamily route handling fix

On Friday 14 September 2007 23:42:52 David Miller wrote:
> 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
>
> Since nobody else found time to review this, I did :-)
>

Thanks for taking the time, and sorry for not getting back on this until
now..

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

Yes, this is what I was worried about. But as I'm not that familiar with 
how these dst_entries are used down the line or with subpolicy 
transformations I didn't feel comfortable rewriting that completely.
I'm trying to get this thing solved (any help is of course appreciated :),
but in the meantime I think the following bit could actually be separated as,
although related, fixes an issue not directly tied to the original problem
(..and would be great to get applied as it makes interfamily work quite ok
for a number of setups). What do you think?

..and for a short description:

This patch resets the ipv4-related flags in the new flow as their content
will otherwise depend on the bits of the ipv6 addresses the struct was 
previously used for. For example, fl4_tos might have RTO_ONLINK set, which
usually prevents the right route from being found.

--
diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index 15aa4c5..b4a0b54 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6/xfrm6_policy.c
@@ -185,6 +185,8 @@ __xfrm6_bundle_create(struct xfrm_policy *policy, struct xfrm_state **xfrm, int
 			case AF_INET:
 				fl_tunnel.fl4_dst = xfrm[i]->id.daddr.a4;
 				fl_tunnel.fl4_src = xfrm[i]->props.saddr.a4;
+				fl_tunnel.fl4_tos = 0;
+				fl_tunnel.fl4_scope = 0;
 				break;
 			case AF_INET6:
 				ipv6_addr_copy(&fl_tunnel.fl6_dst, __xfrm6_bundle_addr_remote(xfrm[i], &fl->fl6_dst));
-
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