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]
Date:	Mon, 4 Feb 2008 09:00:27 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: xfrm_input() and ->seq oddities

On Sun, Feb 03, 2008 at 11:04:44AM +0000, Al Viro wrote:
>
> So what you are saying is
> 	* callers of xfrm_input_resume() are in callbacks that couldn't
> have been set other than from esp_input()/esp6_input()
> 	* these two could have only been called via ->type->input()
> 	* ->type->input() is called from xfrm_input(), immediately after
> having set ->seq.input, *or* from xfrm6_input_addr().  The former is safe.
> 	* xfrm6_input_addr() calls ->type->input() of object it gets from
> xfrm_state_lookup_byaddr().  The protocol number passed to the latter comes
> from xfrm6_input_addr() argument.
> 	* the protocol numbers given to xfrm6_input_addr() by its callers
> are IPPROTO_DSTOPTS and IPPROTO_ROUTING resp; ->input() instances in their
> xfrm_type do *not* set callbacks that could lead to xfrm_input_resume(),
> so we are safe.

This doesn't look so bad if you take out the xfrm6_input_addr call.
And you can't blame that one on me :)

The xfrm6_input_addr function is really a parallel universe which has
nothing to do with IPsec.  It's used by Mobile IPv6 just because it
happened to fit in the same schema.

In other words, IPsec transforms such as ESP cannot be called from
xfrm6_input_addr and as such async resumption never occurs with
xfrm6_input_addr.

> IMO that at least deserves a comment near xfrm_input()...

Sure.  There is already a comment about encap_type < 0 in there, but
I think you'll probably be able to explain it much better than I can
looking in from the outside so if you have a patch... :)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ