NetBSD Problem Report #53922

From coypu@sdf.org  Tue Jan 29 18:20:32 2019
Return-Path: <coypu@sdf.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 "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 348937A1A9
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 29 Jan 2019 18:20:32 +0000 (UTC)
Message-Id: <201901291820.x0TIKHJ4000943@sdf.org>
Date: Tue, 29 Jan 2019 18:20:17 GMT
From: coypu@sdf.org
Reply-To: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Subject: My networking setup makes NetBSD panic
X-Send-Pr-Version: 3.95

>Number:         53922
>Category:       kern
>Synopsis:       My networking setup makes NetBSD panic
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    riastradh
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 29 18:25:00 +0000 2019
>Closed-Date:    Tue Apr 02 22:20:00 +0000 2024
>Last-Modified:  Wed Apr 03 03:39:57 +0000 2024
>Originator:     coypu@sdf.org
>Release:        NetBSD 8.99.30
>Organization:

>Environment:
System: NetBSD planets 8.99.30 NetBSD 8.99.30 (GENERIC) #0: Thu Jan 10 15:02:02 IST 2019 fly@planets:/home/fly/obj2/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
	if I reboot my router, it seems to send a packet that crashes netbsd.
	I've had it occur twice, so I assume it's reproducible.
	This predates pgoyette-compat merge.

	uvm_fault(0xffffec6c70d4bcf8, 0x0, 1) -> e
	fatal page fault in supervisor mode
	trap type 6 code 0 rip 0xffffffff80768ec7 cs 0x8 rflags 0x10246 cr2 0x18 ilevel 0x4 rsp 0xffffc701cdb779f0
	curlwp 0xffffec6c70c8e8a0 pid 211.1 lowest kstack 0xffffc701cdb742c0
	panic: trap
	cpu0: Begin traceback...
	vpanic() at netbsd:vpanic+0x16f
	snprintf() at netbsd:snprintf
	startlwp() at netbsd:startlwp
	alltraps() at netbsd:alltraps+0xc8
	pfil_run_arg.isra.0() at netbsd:pfil_run_arg.isra.0+0xb7
	in6_control() at netbsd:in6_control+0x10c5
	udp6_ioctl_wrapper() at netbsd:udp6_ioctl_wrapper+0x32
	compat_ifioctl() at netbsd:compat_ifioctl+0x12f
	doifioctl() at netbsd:doifioctl+0xbad
	sys_ioctl() at netbsd:sys_ioctl+0x11c
	syscall() at netbsd:syscall+0x173
	--- syscall (number 54) ---
	72f21bf1a74a:
	cpu0: End traceback...

	things running: ntpd, dhcpcd, web browser
	to be explicit, not running: any packet filter

	network interface:
	re0 at pci8 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet (rev. 0x15)
	re0: interrupting at msix3 vec 0
	re0: Ethernet address 40:b0:76:0c:7d:c7
	re0: using 256 tx descriptors
	rgephy0 at re0 phy 7: RTL8251 1000BASE-T media interface, rev. 0

>How-To-Repeat:
	Reboot the router my ISP gave me while a NetBSD machine is connected to it.
>Fix:
	No idea.

>Release-Note:

>Audit-Trail:
From: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/53922: My networking setup makes NetBSD panic
Date: Tue, 29 Jan 2019 18:57:13 +0000

 this picture shows the tcpdump before the panic:
 https://i.imgur.com/UOylbpT.jpg

 Transcribing some parts:
 IP6 (hlim 255, next-header ICMPv6 (50) payload length: 16) fe80::e26e:27b9:ae73:d100 > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
 	source link-address option (1), length 8 (1): 40:b0:76:0c:7d:c7
 		0x000: 48b8 760c 7dc7
 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has Box.Home tell 169.254.92.233, length 28
 dhcpcd: fd53:b8c3:c162:dac0:e570:479e/64: lifetime overflow

 uvm fault...
 stopped at pid 276.1 (dhcpcd) at	netbsd:npf_ifaddrhook+0x55: movq 18(%r12), %rsi

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/53922: My networking setup makes NetBSD panic
Date: Sat, 1 Apr 2023 19:44:25 +0000

 I just realized this has been sitting for four years... did anyone
 ever figure anything out?

 also, in the capture I see "Request who-has 169.254.92.233 tell
 169.254.92.233" and that seems dodgy... (maybe I'm wrong because it's
 been a long time since I last touched arp in any way but I thought
 that should never happen)

 -- 
 David A. Holland
 dholland@netbsd.org

From: Taylor R Campbell <riastradh@NetBSD.org>
To: coypu@sdf.org
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/53922: My networking setup makes NetBSD panic
Date: Fri, 1 Mar 2024 22:42:46 +0000

 The two places in in6_control that obviously lead to pfil_run_arg are
 in SIOCAIFADDR_IN6 (add interface address) and SIOCDIFADDR_IN6 (delete
 interface address):

 https://nxr.netbsd.org/xref/src/sys/netinet6/in6.c?r=3D1.272#711
 https://nxr.netbsd.org/xref/src/sys/netinet6/in6.c?r=3D1.272#719

 These are both pfil_run_addrhooks(if_pfil, ...), which means that the
 only callbacks are installed with pfil_add_ihook(..., PFIL_IFADDR,
 if_pfil).  There are only two calls matching these patterns, in pf(4)
 with pfil_ifaddr_wrapper and in and npf(4) with npf_ifaddrhook:

 https://nxr.netbsd.org/xref/src/sys/dist/pf/net/pf_if.c?r=3D1.33#142
 https://nxr.netbsd.org/xref/src/sys/net/npf/npf_os.c?r=3D1.10#412

 Note that these hooks are installed unconditionally at boot time,
 irrespective of whether pf or npf is in use.  (I doubt pf is loaded
 because it's only ever been a loadable module, right?  So it's
 probably npf -- but it doesn't matter, because they do the same thing
 here.)

 The argument passed to pfil_run_addrhooks is struct ifaddr *ifa, and
 both pf and npf do ifa->ifa_ifp:

 https://nxr.netbsd.org/xref/src/sys/dist/pf/net/pf_if.c?r=3D1.33#142
 https://nxr.netbsd.org/xref/src/sys/net/npf/npf_os.c?r=3D1.10#386

 The fault address in %cr2 is 0x18, and:

 (gdb) print &((struct ifaddr *)0)->ifa_ifp
 $1 =3D (struct ifnet **) 0x18

 So my guess is that the argument passed to the pfil hooks, namely,
 &ia->ia_ifa for struct in6_ifaddr *ia (note that ia_ifa is the first
 member, so this address is the same as ia), is null.

 Going back to the call sites in in6_control, we have:

 (SIOCDIFADDR_IN6)
     717 		ifaref(&ia->ia_ifa);
     718 		in6_purgeaddr(&ia->ia_ifa);
     719 		pfil_run_addrhooks(if_pfil, cmd, &ia->ia_ifa);

 I don't think it is possible for ia to be null at this point, because
 all that ifaref(ifa) does is atomic_inc_uint(&ifa->ifa_refcnt):

 https://nxr.netbsd.org/xref/src/sys/net/if.c?r=3D1.443#1792

 And that would crash if ifa wre null, so ifaref(&ia->ia_ifa) would
 crash if ia were null.

 This leaves, as the only other option:

 (SIOCAIFADDR_IN6)
     706 		int s =3D splsoftnet();
     707 		error =3D in6_update_ifa1(ifp, ifra, &ia, &psref, 0);
     708 		splx(s);
     709 		if (error)
     710 			break;
     711 		pfil_run_addrhooks(if_pfil, cmd, &ia->ia_ifa);

 Can ia be null here?  In other words, can in6_update_ifa1 return 0
 while ia is null on exit?  I think yes, and in only one case: in the
 case that ifra->ifra_lifetime.ia6t_vltime =3D=3D 0, i.e., the valid
 lifetime of the address being added is zero:

 https://nxr.netbsd.org/xref/src/sys/netinet6/in6.c?r=3D1.272#1148

    1148 	if (lt->ia6t_vltime =3D=3D 0) {
    1149 		/*
    1150 		 * the following log might be noisy, but this is a typical
    1151 		 * configuration mistake or a tool's bug.
    1152 		 */
    1153 		nd6log(LOG_INFO, "valid lifetime is 0 for %s\n",
    1154 		    IN6_PRINT(ip6buf, &ifra->ifra_addr.sin6_addr));
    1155=20
    1156 		if (ia =3D=3D NULL)
    1157 			return 0; /* there's nothing to do */
    1158 	}

 How can this happen?  Well, there's a branch in dhcpcd that sets
 dhcpcd's ia->prefix_vltime (which is later passed as
 ifra->ifra_lifetime.ia6t_vltime) to zero, and prints `lifetime
 overflow' as maya's screenshot indicates (using cvsweb instead of nxr
 since nxr doesn't index external/):

 http://cvsweb.netbsd.org/bsdweb.cgi/src/external/bsd/dhcpcd/dist/src/ipv6.c=
 ?rev=3D1.1.1.12&content-type=3Dtext/x-cvsweb-markup

 		if (ia->prefix_vltime !=3D ND6_INFINITE_LIFETIME) {
 			ia->prefix_vltime -=3D (uint32_t)n.tv_sec;
 			/* This should never happen. */
 			if (ia->prefix_vltime > vltime) {
 				logerrx("%s: %s: lifetime overflow",
 				    ifp->name, ia->saddr);
 				ia->prefix_vltime =3D ia->prefix_pltime =3D 0;
 			}
 		}

 The log message has since been deleted but the logic is still there in
 HEAD to set prefix_vltime=3D0.

 The log message nd6log(LOG_INFO, ...) didn't show up in the screenshot
 presumably because nd6_debug=3D0.


 So I think maybe maya's ISP tried to delete an address or something by
 publishing a router advertisement with an interface address having
 valid lifetime zero (or possibly <1sec), and NetBSD responded by
 curling up into a ball, and the PR got hidden in confidential gnats
 state where nobody looked for several years.

 Test case should be to just issue ioctl(SIOCAIFADDR_IN6) with the
 right input.

 Fix should be to change `if (error)' to `if (error || ia =3D=3D NULL)',
 with a comment explaining why.

From: Taylor R Campbell <riastradh@NetBSD.org>
To: coypu@sdf.org
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/53922: My networking setup makes NetBSD panic
Date: Fri, 1 Mar 2024 22:51:02 +0000

 Reproducer: ifconfig lo0 inet6 fd00::1/64 pltime 0 vltime 0

From: Taylor R Campbell <riastradh@NetBSD.org>
To: coypu@sdf.org
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/53922: My networking setup makes NetBSD panic
Date: Fri, 1 Mar 2024 23:06:32 +0000

 This is a multi-part message in MIME format.
 --=_U+89j2l9CEBqI2aSXBW9qNw7GOwXDlcv


 --=_U+89j2l9CEBqI2aSXBW9qNw7GOwXDlcv
 Content-Type: text/plain; charset="ISO-8859-1"; name="pr53922-iavltime0"
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: attachment; filename="pr53922-iavltime0.patch"

 From d63fb6fa402493034f2217bcb6bf55c84b003299 Mon Sep 17 00:00:00 2001
 From: Taylor R Campbell <riastradh@NetBSD.org>
 Date: Fri, 1 Mar 2024 23:05:31 +0000
 Subject: [PATCH] netinet6: Avoid NPD on `ifconfig ifN inet6 ... pltime 0
  vltime 0'.

 PR kern/53922
 ---
  sys/netinet6/in6.c | 9 ++++++++-
  1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/sys/netinet6/in6.c b/sys/netinet6/in6.c
 index 9814edf357ce..f16818085099 100644
 --- a/sys/netinet6/in6.c
 +++ b/sys/netinet6/in6.c
 @@ -726,7 +726,14 @@ in6_control1(struct socket *so, u_long cmd, void *data=
 , struct ifnet *ifp)
  		int s =3D splsoftnet();
  		error =3D in6_update_ifa1(ifp, ifra, &ia, &psref, 0);
  		splx(s);
 -		if (error)
 +		/*
 +		 * in6_update_ifa1 doesn't create the address if its
 +		 * valid lifetime (vltime) is zero, since we would just
 +		 * delete the address immediately in that case anyway.
 +		 * So it may succeed but return null ia.  In that case,
 +		 * nothing left to do.
 +		 */
 +		if (error || ia =3D=3D NULL)
  			break;
  		pfil_run_addrhooks(if_pfil, cmd, &ia->ia_ifa);
  		break;

 --=_U+89j2l9CEBqI2aSXBW9qNw7GOwXDlcv--

From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53922 CVS commit: src/sys/netinet6
Date: Fri, 1 Mar 2024 23:50:28 +0000

 Module Name:	src
 Committed By:	riastradh
 Date:		Fri Mar  1 23:50:28 UTC 2024

 Modified Files:
 	src/sys/netinet6: in6.c

 Log Message:
 netinet6: Avoid NPD on `ifconfig ifN inet6 ... pltime 0 vltime 0'.

 PR kern/53922


 To generate a diff of this commit:
 cvs rdiff -u -r1.291 -r1.292 src/sys/netinet6/in6.c

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

State-Changed-From-To: open->pending-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Fri, 01 Mar 2024 23:57:07 +0000
State-Changed-Why:
pullup-10 #619
pullup-9 #1812
pullup-8 #1944


From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53922 CVS commit: [netbsd-10] src/sys/netinet6
Date: Sun, 10 Mar 2024 19:11:07 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sun Mar 10 19:11:07 UTC 2024

 Modified Files:
 	src/sys/netinet6 [netbsd-10]: in6.c

 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #619):

 	sys/netinet6/in6.c: revision 1.292

 netinet6: Avoid NPD on `ifconfig ifN inet6 ... pltime 0 vltime 0'.
 PR kern/53922


 To generate a diff of this commit:
 cvs rdiff -u -r1.288.2.2 -r1.288.2.3 src/sys/netinet6/in6.c

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

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53922 CVS commit: [netbsd-9] src/sys/netinet6
Date: Sun, 10 Mar 2024 19:12:05 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sun Mar 10 19:12:05 UTC 2024

 Modified Files:
 	src/sys/netinet6 [netbsd-9]: in6.c

 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #1812):

 	sys/netinet6/in6.c: revision 1.292

 netinet6: Avoid NPD on `ifconfig ifN inet6 ... pltime 0 vltime 0'.
 PR kern/53922


 To generate a diff of this commit:
 cvs rdiff -u -r1.275.2.2 -r1.275.2.3 src/sys/netinet6/in6.c

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

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53922 CVS commit: [netbsd-8] src/sys/netinet6
Date: Sun, 10 Mar 2024 19:13:09 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sun Mar 10 19:13:09 UTC 2024

 Modified Files:
 	src/sys/netinet6 [netbsd-8]: in6.c

 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #1944):

 	sys/netinet6/in6.c: revision 1.292

 netinet6: Avoid NPD on `ifconfig ifN inet6 ... pltime 0 vltime 0'.
 PR kern/53922


 To generate a diff of this commit:
 cvs rdiff -u -r1.245.2.14 -r1.245.2.15 src/sys/netinet6/in6.c

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

Responsible-Changed-From-To: kern-bug-people->riastradh
Responsible-Changed-By: riastradh@NetBSD.org
Responsible-Changed-When: Tue, 02 Apr 2024 22:20:00 +0000
Responsible-Changed-Why:
mine


State-Changed-From-To: pending-pullups->closed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Tue, 02 Apr 2024 22:20:00 +0000
State-Changed-Why:
fixed and pulled up to 10, 9, 8


>Unformatted:

Home	PR Database Search