netdev - Re: [RFC PATCH]xfrm: fix perpetual bundles

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: <20100302112754.GA1513@gondor.apana.org.au>
Date:	Tue, 2 Mar 2010 19:27:54 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	jamal <hadi@...erus.ca>
Cc:	davem@...emloft.net, kaber@...sh.net, yoshfuji@...ux-ipv6.org,
	nakam@...ux-ipv6.org, eric.dumazet@...il.com,
	netdev@...r.kernel.org
Subject: Re: [RFC PATCH]xfrm: fix perpetual bundles

On Wed, Feb 24, 2010 at 08:19:24AM -0500, jamal wrote:
> 
> Apologies for the shotgun email but this has been perplexing me for
> sometime and i am worried the the patch i have is a band-aid (although
> it fixes the problem), so here's a long-winded description..

First of all I don't think patch fixes the root (or rather, roots)
of the problem.

> 1)In the connect() stage, in the slow path a route cache is
> created with the rth->fl.fl4_src of 0.0.0.0...
> ==> policy->bundles is empty, so we do a lookup, fail, create
> one.. (remember rth->fl.fl4_src of 0.0.0.0 at this stage and
> thats what we end storing in the bundle/xdst for later comparison
> instead of the skb's fl)

So this is root number 1.  When this stuff was first written this
case simply wasn't possible.  So I think the question we need to
ask here is can we get a valid address there at the connect stage?

After all, for non-IPsec connect(2)s, you do get a valid IP address.
So I don't see why the IPsec case should be different.

Creating a bundle with a zero source address is just a hack to
make connect(2) succeed immediately.  AFAICS getting a valid IP
address can also be done without waiting for the whole IPsec state
to be created.

Of course if anybody is still interested we could also revisit
the neighbouresque queueing idea.

> 2)ping sends a packet (does a sendmsg) 
> ==> xfrm_find_bundle() ends up comparing skb's->fl (non-zero
> fl->fl4_src) with what we stored from #1b. Fails.
> ==> we create a new bundle at attach the old one at the end of it.
> ...and now policy->bundles has two xdst entries

This is the way it's supposed to work.

> 3) Repeat #2, and now we have 3 xdsts in policy bundles

This is what I don't understand.  The code is supposed to look
at every bundle attached to the policy.  So why doesn't it find
the one we created at step #2?

In conclusion, I think we have two problems, with the second
one being the most immediate cause of your symptoms.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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