net/xfrm: Fix lookups for states with spi == 0

It seems to be a valid use case to add xfrm state without
Security Parameter Indexes (SPI) value associated:
ip xfrm state add src $src dst $dst proto $proto mode $mode sel src $src dst $dst $algo

The bad thing is that it's currently impossible to get/delete the state
without SPI: __xfrm_state_insert() obviously doesn't add hash for zero
SPI in xfrm.state_byspi, and xfrm_user_state_lookup() will fail as
xfrm_state_lookup() does lookups by hash.

It also isn't possible to workaround from userspace as
xfrm_id_proto_match() will be always true for ah/esp/comp protos.

So, don't try looking up by hash if SPI == 0.

Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
 net/xfrm/xfrm_user.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On Wed, May 02, 2018 at 03:02:20AM +0100, Dmitry Safonov wrote:
> It seems to be a valid use case to add xfrm state without
> Security Parameter Indexes (SPI) value associated:
> ip xfrm state add src $src dst $dst proto $proto mode $mode sel src $src dst $dst $algo
> 
> The bad thing is that it's currently impossible to get/delete the state
> without SPI: __xfrm_state_insert() obviously doesn't add hash for zero
> SPI in xfrm.state_byspi, and xfrm_user_state_lookup() will fail as
> xfrm_state_lookup() does lookups by hash.
> 
> It also isn't possible to workaround from userspace as
> xfrm_id_proto_match() will be always true for ah/esp/comp protos.
> 
> So, don't try looking up by hash if SPI == 0.
> 
> Cc: Steffen Klassert <steffen.klassert@secunet.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Dmitry Safonov <dima@arista.com>

A zero SPI is illegal for many IPsec protocols because that value
is used for other purposes, e.g., IKE encapsulation.

Cheers,

On Wed, 2018-05-02 at 17:11 +0800, Herbert Xu wrote:
> On Wed, May 02, 2018 at 03:02:20AM +0100, Dmitry Safonov wrote:
> > It seems to be a valid use case to add xfrm state without
> > Security Parameter Indexes (SPI) value associated:
> > ip xfrm state add src $src dst $dst proto $proto mode $mode sel src
> > $src dst $dst $algo
> > 
> > The bad thing is that it's currently impossible to get/delete the
> > state
> > without SPI: __xfrm_state_insert() obviously doesn't add hash for
> > zero
> > SPI in xfrm.state_byspi, and xfrm_user_state_lookup() will fail as
> > xfrm_state_lookup() does lookups by hash.
> > 
> > It also isn't possible to workaround from userspace as
> > xfrm_id_proto_match() will be always true for ah/esp/comp protos.
> > 
> > So, don't try looking up by hash if SPI == 0.
> > 
> > Cc: Steffen Klassert <steffen.klassert@secunet.com>
> > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: netdev@vger.kernel.org
> > Signed-off-by: Dmitry Safonov <dima@arista.com>
> 
> A zero SPI is illegal for many IPsec protocols because that value
> is used for other purposes, e.g., IKE encapsulation.

But still it's possible to create ipsec with zero SPI.
And it seems not making sense to search for a state with SPI hash if
request has zero SPI.

On Wed, May 02, 2018 at 01:41:36PM +0100, Dmitry Safonov wrote:
>
> But still it's possible to create ipsec with zero SPI.
> And it seems not making sense to search for a state with SPI hash if
> request has zero SPI.

Fair enough.  In fact a zero SPI is legal and defined for IPcomp.

The bug arose from this patch:

commit 7b4dc3600e4877178ba94c7fbf7e520421378aa6
Author: Masahide NAKAMURA <nakam@linux-ipv6.org>
Date:   Wed Sep 27 22:21:52 2006 -0700

    [XFRM]: Do not add a state whose SPI is zero to the SPI hash.
    
    SPI=0 is used for acquired IPsec SA and MIPv6 RO state.
    Such state should not be added to the SPI hash
    because we do not care about it on deleting path.
    
    Signed-off-by: Masahide NAKAMURA <nakam@linux-ipv6.org>
    Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>

I think it would be better to revert this.

Cheers,