netdev - Re: xfrm_input() and ->seq oddities

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: <20080203220027.GA11641@gondor.apana.org.au>
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