Re: toolchain/52257: evbmips64-eb crash in keysock

[Nick Hudson <skrll%netbsd.org@localhost>]

The following reply was made to PR toolchain/52257; it has been noted by GNATS.

From: Nick Hudson <skrll%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost, toolchain-manager%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Cc: 
Subject: Re: toolchain/52257: evbmips64-eb crash in keysock
Date: Thu, 25 May 2017 16:32:57 +0100

 On 05/25/17 16:00, mlelstv%serpens.de@localhost wrote:
 >> Number:         52257
 >> Category:       toolchain
 >> Synopsis:       evbmips64-eb crash in keysock
 >> Confidential:   no
 >> Severity:       critical
 >> Priority:       high
 >> Responsible:    toolchain-manager
 >> State:          open
 >> Class:          sw-bug
 >> Submitter-Id:   net
 >> Arrival-Date:   Thu May 25 15:00:00 +0000 2017
 >> Originator:     Michael van Elst
 >> Release:        NetBSD 7.99.70
 >> Organization:
 > 	
 >> Environment:
 > 	
 > 	
 > System: NetBSD cosmicbunny 7.99.70 NetBSD 7.99.70 (COSMICBUNNY) #27: Tue Apr 25 09:30:20 CEST 2017 mlelstv@gossam:/home/netbsd-current/obj.evbmips64-eb/home/netbsd-current/src/sys/arch/evbmips/compile/COSMICBUNNY evbmips
 > Architecture: mips64eb
 > Machine: evbmips
 >> Description:
 > When initializing ipsec, the kernel crashed with an assertion failure.
 > The assertion message couldn't be captured, but DDB shows the location
 > in the backtrace:
 >
 > | 0x9800000410003770: kern_assert+48 (63061,ffffffff80553a30,ffffffff805641f0,ffff
 > | ffff8056c5d8) ra ffffffff802fd2a4 sz 96
 > | 0x98000004100037d0: key_sendup_mbuf+31c (63061,ffffffff80553a30,ffffffff805641f0
 > | ,ffffffff8056c5d8) ra ffffffff802f12a0 sz 96
 > | 0x9800000410003830: key_acquire+450 (63061,ffffffff80553a30,ffffffff805641f0,fff
 > | fffff8056c5d8) ra ffffffff802f3b28 sz 112
 >
 > which translates to
 >
 > |  /home/netbsd-current/src/sys/netipsec/keysock.c:300 (discriminator 1)
 > |         KASSERT(so != NULL || target != KEY_SENDUP_ONE);
 >
 > The assertion however fails only because the compiler didn't evaluate
 > the conditions properly.
 
 I compiled it locally and got...
 
 
 
 ffffffff802f15d8 <key_sendup_mbuf>:
 {
 ffffffff802f15d8:       67bdffa0        daddiu  sp,sp,-96
 ffffffff802f15dc:       ffb30028        sd      s3,40(sp)
 ffffffff802f15e0:       00a09825        move    s3,a1
 ffffffff802f15e4:       ffb20020        sd      s2,32(sp)
 ffffffff802f15e8:       00c09025        move    s2,a2
 ffffffff802f15ec:       ffb00010        sd      s0,16(sp)
 ffffffff802f15f0:       00808025        move    s0,a0
 ffffffff802f15f4:       ffbf0058        sd      ra,88(sp)
 ffffffff802f15f8:       ffbe0050        sd      s8,80(sp)
 ffffffff802f15fc:       ffb70048        sd      s7,72(sp)
 ffffffff802f1600:       ffb60040        sd      s6,64(sp)
 ffffffff802f1604:       ffb50038        sd      s5,56(sp)
 ffffffff802f1608:       ffb40030        sd      s4,48(sp)
          KASSERT(m != NULL);
 ffffffff802f160c:       10a000a4        beqz    a1,ffffffff802f18a0 
 <key_sendup_mbuf+0x2c8>
 
 Here's the test for m == NULL and jump to kassert code.
 
 
 ffffffff802f1610:       ffb10018        sd      s1,24(sp)
          KASSERT(so != NULL || target != KEY_SENDUP_ONE);
 ffffffff802f1614:       120000ae        beqz    s0,ffffffff802f18d0 
 <key_sendup_mbuf+0x2f8>
 
 Here's the jump if so == NULL
 
 ffffffff802f1618:       3a550002        xori    s5,s2,0x2
 ffffffff802f161c:       24020003        li      v0,3
 ffffffff802f1620:       0015100b        movn    v0,zero,s5
 ...
 
 
          KASSERT(m != NULL);
 ffffffff802f18a0:       3c078056        lui     a3,0x8056
 ffffffff802f18a4:       3c068055        lui     a2,0x8055
 ffffffff802f18a8:       3c058054        lui     a1,0x8054
 ffffffff802f18ac:       3c048054        lui     a0,0x8054
 ffffffff802f18b0:       24080131        li      a4,305
 ffffffff802f18b4:       64e79ff8        daddiu  a3,a3,-24584
 ffffffff802f18b8:       64c61ec0        daddiu  a2,a2,7872
 ffffffff802f18bc:       64a52128        daddiu  a1,a1,8488
 ffffffff802f18c0:       0c147ad8        jal     ffffffff8051eb60 
 <kern_assert>
 ffffffff802f18c4:       64842090        daddiu  a0,a0,8336
          KASSERT(so != NULL || target != KEY_SENDUP_ONE);
 ffffffff802f18c8:       1600ff54        bnez    s0,ffffffff802f161c 
 <key_sendup_mbuf+0x44>
 ffffffff802f18cc:       3a550002        xori    s5,s2,0x2
 
 
 Here's the test that target is not KEY_SENDUP_ONE (zero)
 
 ffffffff802f18d0:       1640ff52        bnez    s2,ffffffff802f161c 
 <key_sendup_mbuf+0x44>
 ffffffff802f18d4:       3a550002        xori    s5,s2,0x2
 ffffffff802f18d8:       3c078056        lui     a3,0x8056
 ffffffff802f18dc:       3c068056        lui     a2,0x8056
 ffffffff802f18e0:       3c058054        lui     a1,0x8054
 ffffffff802f18e4:       3c048054        lui     a0,0x8054
 ffffffff802f18e8:       24080132        li      a4,306
 ffffffff802f18ec:       64e79ff8        daddiu  a3,a3,-24584
 ffffffff802f18f0:       64c6a110        daddiu  a2,a2,-24304
 ffffffff802f18f4:       64a52128        daddiu  a1,a1,8488
 ffffffff802f18f8:       0c147ad8        jal     ffffffff8051eb60 
 <kern_assert>
 ffffffff802f18fc:       64842090        daddiu  a0,a0,8336