NetBSD Problem Report #56904

From www@netbsd.org  Sun Jun 26 23:01:02 2022
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_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 A59551A921F
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 26 Jun 2022 23:01:02 +0000 (UTC)
Message-Id: <20220626230101.1211F1A9239@mollari.NetBSD.org>
Date: Sun, 26 Jun 2022 23:01:01 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: null pointer dereference in rtsock.c sysctl_iflist: ifp->if_dl->ifa_addr when ifp->if_dl is null
X-Send-Pr-Version: www-1.0

>Number:         56904
>Category:       kern
>Synopsis:       null pointer dereference in rtsock.c sysctl_iflist: ifp->if_dl->ifa_addr when ifp->if_dl is null
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 26 23:05:00 +0000 2022
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
Thought NetBSD Fendation
>Environment:
syzbot amd64
>Description:
[ 100.1167764] fatal page fault in supervisor mode
[ 100.1167764] trap type 6 code 0 rip 0xffffffff859e1707 cs 0x8 rflags 0x10246 cr2 0 ilevel 0x4 rsp 0xffffea00878e7980
[ 100.1316679] curlwp 0xffffea0012ae3340 pid 600.600 lowest kstack 0xffffea00878e02c0
kernel: page fault trap, code=0
Stopped in pid 600.600 (dhcpcd) at      netbsd:sysctl_rtable+0x1027:    movq    0(%r14),%r12
?
sysctl_rtable() at netbsd:sysctl_rtable+0x1027 sysctl_iflist sys/net/rtsock.c:319 [inline]
sysctl_rtable() at netbsd:sysctl_rtable+0x1027 sys/net/rtsock.c:477
sysctl_dispatch() at netbsd:sysctl_dispatch+0x526 sys/kern/kern_sysctl.c:461
sys___sysctl() at netbsd:sys___sysctl+0x654 sys/kern/kern_sysctl.c:317
syscall() at netbsd:syscall+0x60c sy_invoke sys/sys/syscallvar.h:94 [inline]
syscall() at netbsd:syscall+0x60c sys/arch/x86/x86/syscall.c:138
--- syscall (number 202) ---

It looks like ifp->if_dl can be set by if_deactivate_sadl, which is called by if_free_sadl, which is called by if_alloc_sadl, which is called by if_set_sadl, which can be called while an interface is attached (i.e., between if_register/if_attach and if_detach) and thus while it may be passively in use by net/rtsock.c.
>How-To-Repeat:
https://syzkaller.appspot.com/bug?id=8edb5d051112e79fb98d52ee454a2e7d5ae2ec0e
>Fix:
Yes, please!

Access to ifp->if_dl should probably be managed with atomics and net/rtsock.c should gracefully handle the case of a null sadl, if this is possible -- or if it is invalid, then the transition from an old sadl to a new sadl must be done atomically without an intermediate null state.

Home	PR Database Search