https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230498
--- Comment #16 from Andrey V. Elsukov <a...@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 ?
>
> Index: rtsock.c
> ===================================================================
> --- rtsock.c (revision 339318)
> +++ rtsock.c (working copy)
> @@ -1556,8 +1556,10 @@
> rt_mask(rt), &ss);
> info.rti_info[RTAX_GENMASK] = 0;
> if (rt->rt_ifp) {
> - info.rti_info[RTAX_IFP] = rt->rt_ifp->if_addr->ifa_addr;
> - info.rti_info[RTAX_IFA] = rt->rt_ifa->ifa_addr;
> + if (rt->rt_ifp->if_addr)
> + info.rti_info[RTAX_IFP] =
> rt->rt_ifp->if_addr->ifa_addr;
> + if (rt->rt_ifa)
> + info.rti_info[RTAX_IFA] = rt->rt_ifa->ifa_addr;
> if (rt->rt_ifp->if_flags & IFF_POINTOPOINT)
> info.rti_info[RTAX_BRD] = rt->rt_ifa->ifa_dstaddr;
> }
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 memory
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.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
