NetBSD Problem Report #56836

From www@netbsd.org  Sat May 14 18:50:51 2022
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id A16351A923C
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 14 May 2022 18:50:51 +0000 (UTC)
Message-Id: <20220514185048.D61541A923C@mollari.NetBSD.org>
Date: Sat, 14 May 2022 18:50:48 +0000 (UTC)
From: andrew.cagney@gmail.com
Reply-To: andrew.cagney@gmail.com
To: gnats-bugs@NetBSD.org
Subject: IPv6 ESN tunneling IPcomp has corrupt header
X-Send-Pr-Version: www-1.0

>Number:         56836
>Category:       kern
>Synopsis:       IPv6 ESN tunneling IPcomp has corrupt header
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat May 14 18:55:00 +0000 2022
>Last-Modified:  Thu Oct 20 15:30:02 +0000 2022
>Originator:     Andrew Cagney
>Release:        9.2
>Organization:
>Environment:
9.2
>Description:
Below are two packets received by a linux host where the peers are configured to IPsec packets with IPv6 IPcomp + ESP + IPv6

- the first was sent by netbsd; linux rejects it

12:22:02.360081 IP6 (hlim 64, next-header ESP (50) payload length: 60)
2001:db8:1:2::45 > 2001:db8:1:2::23: ESP(spi=0x14df9f91,seq=0x6),
length 60
0x0000:  1200 0064 6423 1200 0064 6445 86dd 6000  ...dd#...ddE..`.
0x0010:  0000 003c 3240 2001 0db8 0001 0002 0000  ...<2@..........
0x0020:  0000 0000 0045 2001 0db8 0001 0002 0000  .....E..........
0x0030:  0000 0000 0023 14df 9f91 0000 0006 2900  .....#........).
0x0040:  0002 4b60 0002 072b 0705 46de 1d40 1623  ..K`...+..F..@.#
0x0050:  0318 3085 40f9 4c30 7e03 834c 33d3 5306  ..0.@.L0~..L3.S.
0x0060:  b201 0001 016c 5c17 5eca c317 ec65 8e94 45e0

- the second was sent by linux, it was accepted:

14:00:41.418470 IP6 (flowlabel 0x6a92b, hlim 64, next-header ESP (50)
payload length: 112) 2001:db8:1:2::45 > 2001:db8:1:2::23:
ESP(spi=0xc9a65a98,seq=0x1d), length 112
0x0000:  1200 0064 6423 1200 0064 6445 86dd 6006  ...dd#...ddE..`.
0x0010:  a92b 0070 3240 2001 0db8 0001 0002 0000  .+.p2@..........
0x0020:  0000 0000 0045 2001 0db8 0001 0002 0000  .....E..........
0x0030:  0000 0000 0023 c9a6 5a98 0000 001d 2900  .....#..Z.....).
0x0040:  96c4 4b60 5ba9 cde0 60e5 a0c0 c8bb 8381  ..K`[...`.......
0x0050:  8181 9101 0c98 42a0 7c26 18bf 8161 df86  ......B.|&...a..
0x0060:  c0c9 0c8c 1eef ea93 4022 b5ff b9c0 3202  ........@"....2.
0x0070:  8242 c222 a262 e212 9252 d232 b272 f20a  .B.".b...R.2.r..
0x0080:  8a4a ca2a aa6a ea1a 9a5a da3a ba7a fa06  .J.*.j...Z.:.z..
0x0090:  8646 c626 a666 e600 006c b9fc 757a 76f2  .F.&.f...l..uzv.
0x00a0:  51bf 45d8 50ce                           Q.E.P.

note what follows what I'm pretty sure is SPI+SEQ in the two packets.

From NetBSD we have:

>   14df 9f91 0000 0006 (SPI+SEQ) 2900 0002

but it should be:

>   2900 a970 (i.e., next-header|flags|cpi where the CPI is below:

> 2001:db8:1:2::45 2001:db8:1:2::23
>         ipcomp mode=any spi=43376(0x0000a970) reqid=16390(0x00004006)

Where as from linux we have:

>   c9a6 5a98 0000 001d (SPI+SEQ) 2900 96c4

with its CPI:

src 2001:db8:1:2::45 dst 2001:db8:1:2::23
proto comp spi 0x000096c4 reqid 1 mode tunnel
>How-To-Repeat:
For reference, these are the parameters from NetBSD, hopefully the problem isn't there:

2001:db8:1:2::45 2001:db8:1:2::23
        ipcomp mode=any spi=43376(0x0000a970) reqid=16390(0x00004006)
        C: deflate      seq=0x00000000 replay=0 flags=0x00000000 state=mature
        created: May 14 15:50:22 2022   current: May 14 16:34:23 2022
        diff: 2641(s)   hard: 28800(s)  soft: 28800(s)
        last: May 14 16:31:23 2022      hard: 0(s)      soft: 0(s)
        current: 539(bytes)     hard: 0(bytes)  soft: 0(bytes)
        allocated: 7    hard: 0 soft: 0
        sadb_seq=1 pid=1046 refcnt=0
2001:db8:1:2::45 2001:db8:1:2::23
        esp mode=any spi=350199697(0x14df9f91) reqid=16389(0x00004005)
        E: null
        A: hmac-sha1  7f4bcd34 550b9122 c3b2592f c3e6dd2a a78aed66
        seq=0x00000007 replay=64 flags=0x00000000 state=mature
        created: May 14 15:50:22 2022   current: May 14 16:34:23 2022
        diff: 2641(s)   hard: 28800(s)  soft: 28800(s)
        last: May 14 16:31:23 2022      hard: 0(s)      soft: 0(s)
        current: 700(bytes)     hard: 0(bytes)  soft: 0(bytes)
        allocated: 7    hard: 0 soft: 0
        sadb_seq=0 pid=1046 refcnt=0

2001:db8:0:1::/64[any] 2001:db8:0:2::/64[any] 255(reserved)
        out ipsec
        ipcomp/tunnel/2001:db8:1:2::45-2001:db8:1:2::23/require
        esp/transport//require
        spid=2 seq=0 pid=1053
        refcnt=0
>Fix:
Don't combine IPcomp+ESP with IPv6, doing that is crazy.

>Audit-Trail:
From: Andrew Cagney <andrew.cagney@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/56836: IPv6 ESN tunneling IPcomp has corrupt header
Date: Sat, 14 May 2022 21:34:35 -0400

 (yes ESP, not ESN)

 I suspect something to do with code testing for SADB_X_EXT_RAWCPI,
 note this contradiction:

 in key.c RAWCPI==0 means use ->spi:
     case IPPROTO_IPCOMP:
     if ((sav->flags & SADB_X_EXT_RAWCPI) == 0
         && ntohl(sav->spi) >= 0x10000) {
             IPSECLOG(LOG_DEBUG, "invalid cpi for IPComp.\n");
             return(EINVAL);
   }
 but in xform_ipcomp.c RAWCPI != 0 means use ->spi vis:
     if ((sav->flags & SADB_X_EXT_RAWCPI) == 0)
             cpi = sav->alg_enc;
     else
             cpi = ntohl(sav->spi) & 0xffff;

 setting the flag seems to fix packets from NetBSD->linux, but not the reverse.

From: Andrew Cagney <andrew.cagney@gmail.com>
To: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
	gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/56836: IPv6 ESN tunneling IPcomp has corrupt header
Date: Sun, 15 May 2022 09:41:46 -0400

 Looks like a regression introduced by: Add ipv6 support for fast_ipsec

 - IPv4 also suffers the problem; it's just that my packet test packet
 wasn't big enough to be compressed (IPv6 lacks that)
 - the return packet gets dropped by NetBSD ....

From: Andrew Cagney <andrew.cagney@gmail.com>
To: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
	gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/56836: IPv6 ESN tunneling IPcomp has corrupt header
Date: Mon, 16 May 2022 14:13:57 -0400

 (so how do I bundle patches)

 always always send / expect CPI in IPcomp header

 Fixes kern/56836 where an IPsec interop combining compression and
 ESP|AH would fail.

 Since fast ipsec, the outgoing IPcomp header has contained the
 compression algorithm instead of the CPI.  Adding the
 SADB_X_EXT_RAWCPI flag worked around this but ...

 The IPcomp's SADB was unconditionally hashed using the compression
 algorithm instead of the CPI.  This meant that an incoming packet with
 a valid CPI could never match its SADB.
 ---
  sys/netipsec/key.c          | 5 +----
  sys/netipsec/xform_ipcomp.c | 7 +------
  2 files changed, 2 insertions(+), 10 deletions(-)

 diff --git a/sys/netipsec/key.c b/sys/netipsec/key.c
 index 4ad4a8d466d9..11577960f93f 100644
 --- a/sys/netipsec/key.c
 +++ b/sys/netipsec/key.c
 @@ -8755,10 +8755,7 @@ key_savlut_writer_insert_head(struct secasvar *sav)
      KASSERT(mutex_owned(&key_sad.lock));
      KASSERT(!sav->savlut_added);

 -    if (sav->sah->saidx.proto == IPPROTO_IPCOMP)
 -        hash_key = sav->alg_comp;
 -    else
 -        hash_key = sav->spi;
 +    hash_key = sav->spi;

      hash = key_savluthash(&sav->sah->saidx.dst.sa,
          sav->sah->saidx.proto, hash_key, key_sad.savlutmask);
 diff --git a/sys/netipsec/xform_ipcomp.c b/sys/netipsec/xform_ipcomp.c
 index e94a0b471042..69d196bc7e39 100644
 --- a/sys/netipsec/xform_ipcomp.c
 +++ b/sys/netipsec/xform_ipcomp.c
 @@ -527,7 +527,6 @@ ipcomp_output_cb(struct cryptop *crp)
      struct mbuf *m, *mo;
      int error, skip, rlen, roff, flags;
      uint8_t prot;
 -    uint16_t cpi;
      struct ipcomp * ipcomp;
      IPSEC_DECLARE_LOCK_VARIABLE;

 @@ -589,11 +588,7 @@ ipcomp_output_cb(struct cryptop *crp)
  #endif
          }
          ipcomp->comp_flags = 0;
 -
 -        if ((sav->flags & SADB_X_EXT_RAWCPI) == 0)
 -            cpi = sav->alg_enc;
 -        else
 -            cpi = ntohl(sav->spi) & 0xffff;
 +        uint16_t cpi = ntohl(sav->spi) & 0xffff;
          ipcomp->comp_cpi = htons(cpi);

          /* Fix Next Protocol in IPv4/IPv6 header */
 -- 
 2.35.3

From: Andrew Cagney <andrew.cagney@gmail.com>
To: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
	gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/56836: IPv6 ESN tunneling IPcomp has corrupt header
Date: Tue, 24 May 2022 14:49:14 -0400

 One more thing worth noting.  I'm pretty sure that without this
 change, racoon can't interop with itself:

 racoon/pfkey.c hard-wires SADB_X_EXT_RAWCPI which means:

 - outgoing packets do have a correct IPcomp header (i.e., containing
 the CPI), but
 - incoming packets with that correct CPI never match the SA because
 the SA was hashed using the compression algorithm

From: "Christos Zoulas" <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56836 CVS commit: src/sys/netipsec
Date: Wed, 19 Oct 2022 17:28:03 -0400

 Module Name:	src
 Committed By:	christos
 Date:		Wed Oct 19 21:28:03 UTC 2022

 Modified Files:
 	src/sys/netipsec: key.c xform_ipcomp.c

 Log Message:
 PR/56836: Andrew Cagney: IPv6 ESN tunneling IPcomp has corrupt header

 Always always send / expect CPI in IPcomp header

 Fixes kern/56836 where an IPsec interop combining compression and
 ESP|AH would fail.

 Since fast ipsec, the outgoing IPcomp header has contained the
 compression algorithm instead of the CPI.  Adding the
 SADB_X_EXT_RAWCPI flag worked around this but ...

 The IPcomp's SADB was unconditionally hashed using the compression
 algorithm instead of the CPI.  This meant that an incoming packet with
 a valid CPI could never match its SADB.


 To generate a diff of this commit:
 cvs rdiff -u -r1.277 -r1.278 src/sys/netipsec/key.c
 cvs rdiff -u -r1.74 -r1.75 src/sys/netipsec/xform_ipcomp.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Andrew Cagney <andrew.cagney@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: PR/56836 CVS commit: src/sys/netipsec
Date: Thu, 20 Oct 2022 09:57:57 -0400

 Thanks!  I can kill our custom build.  I'll give it a few days and
 then pick up a 9.99 snapshot and test using that.

From: Christos Zoulas <christos@zoulas.com>
To: Andrew Cagney <andrew.cagney@gmail.com>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: PR/56836 CVS commit: src/sys/netipsec
Date: Thu, 20 Oct 2022 11:28:05 -0400

 Thanks for the reminder! I had it in my flagged mail, but have been really b=
 usy!

 christos

 > On Oct 20, 2022, at 9:58 AM, Andrew Cagney <andrew.cagney@gmail.com> wrote=
 :
 >=20
 > =EF=BB=BFThanks!  I can kill our custom build.  I'll give it a few days an=
 d
 > then pick up a 9.99 snapshot and test using that.

Home	PR Database Search