Re: kern/52353: [netbsd-8] A crash in icmpv6 code (?)

[Dominik Bialy <dmb%yenn.ulegend.net@localhost>]

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

From: Dominik Bialy <dmb%yenn.ulegend.net@localhost>
To: Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>
Cc: dmb%yenn.ulegend.net@localhost, gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost,
	gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/52353: [netbsd-8] A crash in icmpv6 code (?)
Date: Thu, 6 Jul 2017 15:17:37 +0200

 --sdtB3X0nJg68CQEu
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, Jul 04, 2017 at 02:25:25PM +0900, Kengo NAKAHARA wrote:
 > Hi,
 >=20
 > Thank you for your quick and detailed reply.
 >=20
 > On 2017/07/03 12:30, Dominik Bialy wrote:
 > > On Sun, Jul 02, 2017 at 11:35:01PM +0000, Kengo NAKAHARA wrote:
 > >> The following reply was made to PR kern/52353; it has been noted by GN=
 ATS.
 > >>
 > >> From: Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>
 > >> To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, gnats-admin@net=
 bsd.org,
 > >>         netbsd-bugs%netbsd.org@localhost
 > >> Cc:=20
 > >> Subject: Re: kern/52353: [netbsd-8] A crash in icmpv6 code (?)
 > >> Date: Mon, 3 Jul 2017 08:33:32 +0900
 > >>
 > >>  Hi,
 > >> =20
 > >>  On 2017/07/01 22:40, dmb%yenn.ulegend.net@localhost wrote:
 > >>  > System: NetBSD yenn 8.0_BETA NetBSD 8.0_BETA (YENN) #6: Mon Jun 26 =
 08:49:07 UTC 2017 builds@yenn:/var/obj/sys/arch/amd64/compile/YENN amd64
 > >> =20
 > >>  It seems you use other than GENERIC kernel config.Could you show your
 > >>  kernel config?
 > >> =20
 > > It is almost GENERIC with: GATEWAY, and altq* options added.  The setup
 > > is somewhat unusual, since I'm using ipf+pf+the old altq
 > >=20
 > > Here's the config:
 > >=20
 > > http://yenn.ulegend.net/~dmb/YENN
 > >=20
 > > Here's dmesg.boot:
 > >=20
 > > http://yenn.ulegend.net/~dmb/dmesg.boot
 > >=20
 > > (The panic in this dmesg is probably unrelated.)
 > >=20
 > > In altq I'm using WFQ over a 0.75 Mbps uplink.
 > >=20
 > >>  > Architecture: x86_64
 > >>  > Machine: amd64
 > >>  >> Description:
 > >>  > yenn# crash -M netbsd.3.core -N netbsd.3
 > >>  > Crash version 8.0_BETA, image version 8.0_BETA.
 > >>  > System panicked: in6_cksum: mbuf too short for IPv6 header
 > >>  > Backtrace from time of crash is available.
 > >>  > crash> bt
 > >>  > _KERNEL_OPT_NARCNET() at 0
 > >>  > ?() at fffffe80a11bcc00
 > >>  > vpanic() at vpanic+0x149
 > >>  > snprintf() at snprintf
 > >>  > in6_cksum() at in6_cksum+0x1a2
 > >>  > _icmp6_input() at _icmp6_input+0xb4
 > >>  > wqinput_work() at wqinput_work+0x88
 > >>  > workqueue_worker() at workqueue_worker+0xbc
 > >>  >=20
 > >>  > yes, IPv6 is via gif(4), but _before_ the patch for MP-fy
 > >>  >> How-To-Repeat:
 > >>  > 	possibly ping the machine for some time (?) with IPv6 on a gif(4) =
 (?)
 > >> =20
 > >>  Which do you use IPv6 over IPv6 or IPv6 over IPv4?
 > >> =20
 > > IPv6 over IPv4 -- he.net tunnelbroker
 >=20
 > Hmm, I guess there may be the issue in combination ALTQ and gif(4).
 > So, I try to reproduce it in my simple environment. That is,
 >     - use two NetBSD-8 machine and connect directly their ethernet ports
 >     - create IPv6 over IPv4 gif(4) between the two machines
 >     - apply below WFQ to the gif(4) psrc, pdst ethernet
 >       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 >       interface wm2 bandwidth 750000 wfq
 >       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 >     - ping6 over gif(4) each other
 > However, I cannot reproduce it yet...
 >=20
 > By the way, ozaki-r@n.o help me to research this issue. He also implements
 > a patch. Could you try below patch?
 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 > diff --git a/sys/netinet6/icmp6.c b/sys/netinet6/icmp6.c
 > index f740932036d..3b45ba8d785 100644
 > --- a/sys/netinet6/icmp6.c
 > +++ b/sys/netinet6/icmp6.c
 > @@ -494,6 +494,15 @@ _icmp6_input(struct mbuf *m, int off, int proto)
 >  		goto freeit;
 >  	}
 > =20
 > +	if (m->m_len < sizeof(struct ip6_hdr)) {
 > +		m =3D m_pullup(m, sizeof(struct ip6_hdr));
 > +		if (m =3D=3D NULL) {
 > +			ICMP6_STATINC(ICMP6_STAT_TOOSHORT);
 > +			icmp6_ifstat_inc(rcvif, ifs6_in_error);
 > +			goto freeit;
 > +		}
 > +	}
 > +
 >  	ip6 =3D mtod(m, struct ip6_hdr *);
 >  	IP6_EXTHDR_GET(icmp6, struct icmp6_hdr *, m, off, sizeof(*icmp6));
 >  	if (icmp6 =3D=3D NULL) {
 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 >=20
 > If the issue is reproduced after applying above patch, could you tell
 > me your detailed network configuration and ipf/pf setting?=20
 > Of course, within the range you can show with no problem.
 >=20
 OK, then I applied the patch, and I'm pinging the machine
 for quite some time.  The uptime is almost 2 days.
 
 Close the PR?  When it'd be needed it could be reopened again, no?
 
 Dominik
 
 --sdtB3X0nJg68CQEu
 Content-Type: application/pgp-signature; name="signature.asc"
 
 -----BEGIN PGP SIGNATURE-----
 
 iQEcBAEBAgAGBQJZXjhxAAoJELx367HD7zyxMi4H/0QGdz6Kmtmi+yF3ohqbvdaP
 nUw/S4hQFSD42AeGy8r4fLvQ2PxXZU98d6N/3mFrfrnjw93iCmfMf3wq52+BwSVD
 pq73jsUOoigEZFyqLNIRFtVMEAwBvR374Vff5OASmPo88PecUM0v7pJE0ZEaHQBW
 8+Ci7ErY18ALibEwYctvFDU639/aGcbDNZvILeC4g26vtovNeIv4LUT7SwYtQm93
 WESHpaXZdI4b3mo90WCLPVE+d0kT9EK1gZtzeeTvOvC18hoZbUmBSa8kmY9OyPpw
 APtMuanhgznYFuAfUZVw2jBQxEqwL4rL0ZnBfKzvEChd8lKGRXiihKAyt6d/qwc=
 =NBRi
 -----END PGP SIGNATURE-----
 
 --sdtB3X0nJg68CQEu--