From nobody Sat May 10 20:41:33 2025 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZvyTS2Pvkz5vpt1 for ; Sat, 10 May 2025 20:41:48 +0000 (UTC) (envelope-from kp@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZvyTS1ZW7z3p2N; Sat, 10 May 2025 20:41:48 +0000 (UTC) (envelope-from kp@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746909708; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ELVn1sQ0PHHJBbzFn+VBtA77XduSS3eyhcTKfSie4hY=; b=WA/+A29N+jw5cYNw1tCCpr8J7tDOT7Pt5WGnHXMhpBrLJw89c1SNtEhprkRpdSaiJboDCC xpAY0jAkvYqtzJ1p4e5IaUNB9+nGMxn5Xq7NCU5+IJMyxmneWug97my5odQGK8V/pJSk8k na2YloF7dvx5gmFf5qzi7B8dQ+bcYehpDvI+jSzbdgRtIJotIB2qjOnWsI/GcPRt+1ldhc 1RWcUpSRRJn2UbSbip1C1Od1YlchLi2SJS3gyRW9zjBnPheORaXLTRRXH5SiI/BsSkcJa4 U7qahAMZSNrKXhA1cAumS3Qfmcg12sK9P7tnevMA+vEflvI+FRyhaGX8yeHgvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1746909708; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ELVn1sQ0PHHJBbzFn+VBtA77XduSS3eyhcTKfSie4hY=; b=vTK9B9ivL4MW9GIHYJduIyOY7OEG+4kRWC7slddGPZlu39MzAh/uU1mcksOIx+g3e5MTLJ PnR7h18KCGFcVFWGbekQGR3RYZpUOrKTijf1t2FnQjh9xtSjarT/1t4aRwen7tmyWj/wYB VeNN/7iY1h7A+g78EgoZmfQzukttYyRo5FLxCZ4HAKEtmJSSEhppJO2mDmjkyeFeVDo1Jq CPqL+MXHbSwlibrl8+3RGGJ8AuOYBqIEpfsqPn7KIpyBot8eofbYnBzmo1rwo+1QRA+QNE sIIGptrfIXfTpxXjwYP+ZHS9bMv/PRkxUG5Br8aPhobEllfPNutTImdnGoto0w== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1746909708; a=rsa-sha256; cv=none; b=buGpsrZ4RZvbGxnJjpkRhl4OU1/Yzm8pVNsFhEY3OVtyB5fsbE4iBn5wwq9rT48RQJ5a5W vWB7D9ypTymA9E4fIdSU1WzTy2lU8s0vshgmufmgmRu3xE/LZ/c0zk2j4ii2aM6Z1f03yW Cvq/crvubk5v9ZlNHSTtMBfS56o5n9/GBZ3zNdMRxGVcRdn1xfYpGSFVZ6BMZVj7ihBbDM U9YbtUqA6Pc1OO+cgbpdnQ5wHQtzm5wS8Xsh1OyqgjpJpy7T7/08vtl2Ou9wvnd+y2MzUC 6HjlravDPyCahZNCQqA5qFBi9ZkZTR/ivo0vaplf/ECA75uA91nQ1iucY+DYYA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R11" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZvyTS0Gn2z172Z; Sat, 10 May 2025 20:41:48 +0000 (UTC) (envelope-from kp@freebsd.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id BA5BE423C0; Sat, 10 May 2025 22:41:45 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Kristof Provost List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (1.0) Subject: Re: IPv6 panic (NULL * deref?) in nd6_ifnet_link_event Date: Sat, 10 May 2025 22:41:33 +0200 Message-Id: <2A2E3017-F6B1-4B96-A6AB-4DD24C544051@freebsd.org> References: <28r32q30-pn96-q513-36s7-pr04166spp8q@yvfgf.mnoonqbm.arg> Cc: net@freebsd.org In-Reply-To: <28r32q30-pn96-q513-36s7-pr04166spp8q@yvfgf.mnoonqbm.arg> To: "Bjoern A. Zeeb" X-Mailer: iPhone Mail (22E252) > On 10 May 2025, at 21:50, Bjoern A. Zeeb w= rote: >=20 > =EF=BB=BFOn Sat, 10 May 2025, Kristof Provost wrote: >=20 >>=20 >>=20 >>>> On 10 May 2025, at 21:32, Bjoern A. Zeeb wrote: >>>=20 >>> =EF=BB=BFHi, >>>=20 >>> main of the last days. >>>=20 >>> Fatal trap 12: page fault while in kernel mode >>> cpuid =3D 2; apic id =3D 02 >>> fault virtual address =3D 0x10 >>> fault code =3D supervisor read data, page not present >>> instruction pointer =3D 0x20:0xffffffff80dbd769 >>> stack pointer =3D 0x28:0xfffffe0106296d60 >>> frame pointer =3D 0x28:0xfffffe0106296d70 >>> code segment =3D base 0x0, limit 0xfffff, type 0x1b >>> =3D DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags =3D interrupt enabled, resume, IOPL =3D 0 >>> current process =3D 12 (swi6: task queue) >>> rdi: fffff8002f997800 rsi: 000000000000001c rdx: 0000000000000000 >>> rcx: 0000000000010000 r8: 0000000000000001 r9: ffffffffffffffff >>> rax: 0000000000000000 rbx: fffff8002f997a18 rbp: fffffe0106296d70 >>> r10: ffffffff81c4a1e8 r11: 0000000000000001 r12: fffff80001210700 >>> r13: fffff80001210728 r14: fffff8002f997800 r15: 0000000000000001 >>> trap number =3D 12 >>> panic: page fault >>> cpuid =3D 2 >>> time =3D 1746903751 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0106= 296a90 >>> vpanic() at vpanic+0x136/frame 0xfffffe0106296bc0 >>> panic() at panic+0x43/frame 0xfffffe0106296c20 >>> trap_pfault() at trap_pfault+0x48d/frame 0xfffffe0106296c90 >>> calltrap() at calltrap+0x8/frame 0xfffffe0106296c90 >>> --- trap 0xc, rip =3D 0xffffffff80dbd769, rsp =3D 0xfffffe0106296d60, rb= p =3D 0xfffffe0106296d70 --- >>> nd6_ifnet_link_event() at nd6_ifnet_link_event+0x39/frame 0xfffffe010629= 6d70 >>> do_link_state_change() at do_link_state_change+0x1b1/frame 0xfffffe01062= 96dc0 >>> taskqueue_run_locked() at taskqueue_run_locked+0x1c2/frame 0xfffffe01062= 96e40 >>> taskqueue_run() at taskqueue_run+0x4d/frame 0xfffffe0106296e60 >>> ithread_loop() at ithread_loop+0x266/frame 0xfffffe0106296ef0 >>> fork_exit() at fork_exit+0x82/frame 0xfffffe0106296f30 >>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0106296f30 >>> --- trap 0x25b01e6e, rip =3D 0x52db004fa566ef34, rsp =3D 0xcadb9a4f3d667= 734, rbp =3D 0xde5a00adbd42c69c --- >>> KDB: enter: panic >>>=20 >>>=20 >>> (gdb) l * nd6_ifnet_link_event+0x39 >>> 0xffffffff80dbd769 is in nd6_ifnet_link_event (sys/netinet6/nd6_rtr.c:32= 7). >>> 322 static void >>> 323 defrtr_ipv6_only_ipf_down(struct ifnet *ifp) >>> 324 { >>> 325 >>> 326 IF_AFDATA_WLOCK(ifp); >>> 327 ND_IFINFO(ifp)->flags &=3D ~ND6_IFF_IPV6_ONLY; >>> 328 IF_AFDATA_WUNLOCK(ifp); >>> 329 } >>> 330 #endif /* EXPERIMENTAL */ >>> 331 >>>=20 >> That may be a known issue. There=E2=80=99s something odd with teardown wh= ere we sometimes clean up af_data for INET6 and still try to send v6 traffic= . I know of panics where there=E2=80=99s a fib6_lookup() that returns a rout= e with no v6 af_data. >> I put a hack in the pfsense tree to make the panic less likely, but I don= =E2=80=99t know what the root cause is. >=20 > This one likely came after the ifp was gone or at least ND_IFINFO(ifp) > was NULL. The first would be a contract violation the second is likely > a bad order/race against queuing. Yeah, that=E2=80=99s the problem.=20 > But here both can avoid panics by > NULL checks (+warning maybe so we can find the root casue)? I believe there are a lot of places that are potentially affected. I don=E2=80= =99t know how realistic it is to add guards to all of them.=20 And it=E2=80=99s rare enough that it=E2=80=99ll be hard to be sure we got th= em all.=20 =E2=80=94=20 Kristof=