Date: Thu, 22 Nov 2018 06:50:11 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 230498] Fatal trap 12: page fault while in kernel mode in sysctl_dumpentry from sysctl NET_RT_DUMP Message-ID: <bug-230498-7501-pwXuqrqq8o@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230498-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-230498-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230498 --- Comment #16 from Andrey V. Elsukov <ae@FreeBSD.org> --- (In reply to ian from comment #13) > I did make a pretty naive fix for this shortly after reporting it as the > system in question was crashing several times a day. Since applying this I > have has no further issues with it. It does mean the application querying > gets back some null pointers, but its likely better the application exits > (if it does not check for NULL pointers) than the entire system crashing ? >=20 > Index: rtsock.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- rtsock.c (revision 339318) > +++ rtsock.c (working copy) > @@ -1556,8 +1556,10 @@ > rt_mask(rt), &ss); > info.rti_info[RTAX_GENMASK] =3D 0; > if (rt->rt_ifp) { > - info.rti_info[RTAX_IFP] =3D rt->rt_ifp->if_addr->ifa_addr; > - info.rti_info[RTAX_IFA] =3D rt->rt_ifa->ifa_addr; > + if (rt->rt_ifp->if_addr) > + info.rti_info[RTAX_IFP] =3D > rt->rt_ifp->if_addr->ifa_addr; > + if (rt->rt_ifa) > + info.rti_info[RTAX_IFA] =3D rt->rt_ifa->ifa_addr; > if (rt->rt_ifp->if_flags & IFF_POINTOPOINT) > info.rti_info[RTAX_BRD] =3D rt->rt_ifa->ifa_dstad= dr; > } rt->rt_ifa should be safe to dereference, since rtentry holds reference to = ifa and it won't be freed. But access to rt_ifp->if_addr is not easy to protect= in stable/11. The problem happens due to interface is destroying in the time, = when we are doing iteration through routes. And even if you add NULL check here, there is not any guarantee that you won't make access to already freed memo= ry in the rtsock_msg_buffer() a bit later, when you will make access to info.rti_info[]. Also I think an application may expect presence of both RTAX_IFP and RTAX_IFA pointers. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230498-7501-pwXuqrqq8o>