NetBSD Problem Report #52151

From clare@csel.org  Mon Apr 10 06:57:50 2017
Return-Path: <clare@csel.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 1469E7A279
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 10 Apr 2017 06:57:50 +0000 (UTC)
Message-Id: <20170410065745.F1F06FE3F@mail.csel.org>
Date: Mon, 10 Apr 2017 15:57:45 +0900 (JST)
From: clare@csel.org
Reply-To: clare@csel.org
To: gnats-bugs@NetBSD.org
Subject: kernel panic in IPsec processing
X-Send-Pr-Version: 3.95

>Number:         52151
>Category:       kern
>Synopsis:       kernel panic in IPsec processing
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    ozaki-r
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 10 07:00:00 +0000 2017
>Closed-Date:    Sun Apr 16 10:38:58 +0000 2017
>Last-Modified:  Sun Apr 16 10:38:58 +0000 2017
>Originator:     DOYASHIKI Shinichi
>Release:        NetBSD 7.99.67 around 2017-04-10
>Organization:
	at home
>Environment:
System: NetBSD kotori.csel.org 7.99.67 NetBSD 7.99.67 (CONOHAVPS) #0: Mon Apr 10 05:28:09 JST 2017 clare@kanako.csel.org:/export/stage/hack/src/sys/arch/amd64/compile/CONOHAVPS amd64
Architecture: x86_64
Machine: amd64
>Description:
	kernel panic generated around IPsec processing.
>How-To-Repeat:
	1) setup IKE and IPsec ESP transport mode over IPv6.
	   I used racoon(8) for IKE.
	2) ping6 from remote site.
	3) see kernel panic as following:

panic: kernel diagnostic assertion "rw_lock_held(&in6_multilock)" failed: file "../../../../netine
t6/mld6.c", line 861
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x140
ch_voltag_convert_in() at netbsd:ch_voltag_convert_in
in6_lookup_multi() at netbsd:in6_lookup_multi+0x77
key_ismyaddr() at netbsd:key_ismyaddr+0x76
key_checkspidup.isra.19() at netbsd:key_checkspidup.isra.19+0x54
key_getspi() at netbsd:key_getspi+0x1c6
key_parse() at netbsd:key_parse+0x725
key_output() at netbsd:key_output+0x162
key_send_wrapper() at netbsd:key_send_wrapper+0x6c
sosend() at netbsd:sosend+0x76f
do_sys_sendmsg_so() at netbsd:do_sys_sendmsg_so+0x272
do_sys_sendmsg() at netbsd:do_sys_sendmsg+0x85
sys_sendto() at netbsd:sys_sendto+0x5c
syscall() at netbsd:syscall+0x1d8
--- syscall (number 133) ---
730147105fba:
cpu0: End traceback...

>Fix:
	unknown

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->ozaki-r
Responsible-Changed-By: ozaki-r@NetBSD.org
Responsible-Changed-When: Mon, 10 Apr 2017 07:26:11 +0000
Responsible-Changed-Why:
Take


From: Ryota Ozaki <ozaki-r@netbsd.org>
To: clare@csel.org
Cc: "gnats-bugs@NetBSD.org" <gnats-bugs@netbsd.org>, kern-bug-people@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/52151: kernel panic in IPsec processing
Date: Mon, 10 Apr 2017 18:59:35 +0900

 On Mon, Apr 10, 2017 at 4:00 PM,  <clare@csel.org> wrote:
 >         Note: There was a bad value `ciritical' for the field `Severity'.
 >         It was set to the default value of `serious'.
 >
 >>Number:         52151
 >>Category:       kern
 >>Synopsis:       kernel panic in IPsec processing
 >>Confidential:   no
 >>Severity:       serious
 >>Priority:       medium
 >>Responsible:    kern-bug-people
 >>State:          open
 >>Class:          sw-bug
 >>Submitter-Id:   net
 >>Arrival-Date:   Mon Apr 10 07:00:00 +0000 2017
 >>Originator:     DOYASHIKI Shinichi
 >>Release:        NetBSD 7.99.67 around 2017-04-10
 >>Organization:
 >         at home
 >>Environment:
 > System: NetBSD kotori.csel.org 7.99.67 NetBSD 7.99.67 (CONOHAVPS) #0: Mon Apr 10 05:28:09 JST 2017 clare@kanako.csel.org:/export/stage/hack/src/sys/arch/amd64/compile/CONOHAVPS amd64
 > Architecture: x86_64
 > Machine: amd64
 >>Description:
 >         kernel panic generated around IPsec processing.
 >>How-To-Repeat:
 >         1) setup IKE and IPsec ESP transport mode over IPv6.
 >            I used racoon(8) for IKE.
 >         2) ping6 from remote site.
 >         3) see kernel panic as following:
 >
 > panic: kernel diagnostic assertion "rw_lock_held(&in6_multilock)" failed: file "../../../../netine
 > t6/mld6.c", line 861
 > cpu0: Begin traceback...
 > vpanic() at netbsd:vpanic+0x140
 > ch_voltag_convert_in() at netbsd:ch_voltag_convert_in
 > in6_lookup_multi() at netbsd:in6_lookup_multi+0x77
 > key_ismyaddr() at netbsd:key_ismyaddr+0x76
 > key_checkspidup.isra.19() at netbsd:key_checkspidup.isra.19+0x54
 > key_getspi() at netbsd:key_getspi+0x1c6
 > key_parse() at netbsd:key_parse+0x725
 > key_output() at netbsd:key_output+0x162
 > key_send_wrapper() at netbsd:key_send_wrapper+0x6c
 > sosend() at netbsd:sosend+0x76f
 > do_sys_sendmsg_so() at netbsd:do_sys_sendmsg_so+0x272
 > do_sys_sendmsg() at netbsd:do_sys_sendmsg+0x85
 > sys_sendto() at netbsd:sys_sendto+0x5c
 > syscall() at netbsd:syscall+0x1d8
 > --- syscall (number 133) ---
 > 730147105fba:
 > cpu0: End traceback...
 >
 >>Fix:

 Could you try the patch?:
   http://www.netbsd.org/~ozaki-r/fix-PR52151.diff

 Thanks,
   ozaki-r

From: DOYASHIKI Shinichi <clare@csel.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/52151: kernel panic in IPsec processing
Date: Mon, 10 Apr 2017 20:10:18 +0900

 On Mon, 10 Apr 2017 10:05:01 +0000 (UTC)
 Ryota Ozaki <ozaki-r@netbsd.org> wrote:
 >  Could you try the patch?:
 >    http://www.netbsd.org/~ozaki-r/fix-PR52151.diff

 Thank you.
 An immediate crash seems to be gone.
 I will look at the situation for a while.

 -- 
 DOYASHIKI Shinichi <clare@csel.org>

From: "Ryota Ozaki" <ozaki-r@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52151 CVS commit: src/sys/netipsec
Date: Mon, 10 Apr 2017 14:02:25 +0000

 Module Name:	src
 Committed By:	ozaki-r
 Date:		Mon Apr 10 14:02:25 UTC 2017

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

 Log Message:
 Fix assertion failure in in6_lookup_multi via key_ismyaddr

 in6_lookup_multi was forgotten to be migrated to in6_multi_group.
 Also psz should be changed to psz/psref because in6_multi_group is
 sleepable.

 Fix PR kern/52151


 To generate a diff of this commit:
 cvs rdiff -u -r1.104 -r1.105 src/sys/netipsec/key.c

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

From: Ryota Ozaki <ozaki-r@netbsd.org>
To: "gnats-bugs@NetBSD.org" <gnats-bugs@netbsd.org>
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, clare@csel.org
Subject: Re: kern/52151: kernel panic in IPsec processing
Date: Mon, 10 Apr 2017 23:07:51 +0900

 On Mon, Apr 10, 2017 at 8:15 PM, DOYASHIKI Shinichi <clare@csel.org> wrote:
 > The following reply was made to PR kern/52151; it has been noted by GNATS.
 >
 > From: DOYASHIKI Shinichi <clare@csel.org>
 > To: gnats-bugs@NetBSD.org
 > Cc:
 > Subject: Re: kern/52151: kernel panic in IPsec processing
 > Date: Mon, 10 Apr 2017 20:10:18 +0900
 >
 >  On Mon, 10 Apr 2017 10:05:01 +0000 (UTC)
 >  Ryota Ozaki <ozaki-r@netbsd.org> wrote:
 >  >  Could you try the patch?:
 >  >    http://www.netbsd.org/~ozaki-r/fix-PR52151.diff
 >
 >  Thank you.
 >  An immediate crash seems to be gone.
 >  I will look at the situation for a while.

 Thank you for the test. I committed the fix.

 I think the issue has gone though, I'll wait some days
 in case before closing the PR.

  ozaki-r

From: DOYASHIKI Shinichi <clare@csel.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/52151: kernel panic in IPsec processing
Date: Sat, 15 Apr 2017 16:55:13 +0900

 On Mon, 10 Apr 2017 14:10:00 +0000 (UTC)
 Ryota Ozaki <ozaki-r@netbsd.org> wrote:

 >  Thank you for the test. I committed the fix.
 >  
 >  I think the issue has gone though, I'll wait some days
 >  in case before closing the PR.
 >  
 >   ozaki-r
 >  

 Although it is used for connection between bases,
 The kernel seems to regain stability.
 Thank you.


 -- 
 DOYASHIKI Shinichi <clare@csel.org>

State-Changed-From-To: open->closed
State-Changed-By: ozaki-r@NetBSD.org
State-Changed-When: Sun, 16 Apr 2017 10:38:58 +0000
State-Changed-Why:
The reporter confirmed fixed. Thanks.


>Unformatted:

Home	PR Database Search