In rtrequest and rtinit check for sa_len != 0 for the given

destination. These checks are needed so we do not install
a route looking like this:
(0)                192.0.2.200        UH       tun0 =>

When removing this route  the kernel will start to walk
the address space which looks like a hang on 64bit platforms
because it'll take ages while on 32bit you should see a panic
when kernel debugging options are turned on.

The problem is in rtrequest1:
	if (netmask) {
		rt_maskedcopy(dst, ndst, netmask);
	} else
		bcopy(dst, ndst, dst->sa_len);

In both cases the len might be 0 if the application forgot to
set it.  If so ndst will be all-zero  leading to above
mentioned strange routes.

This is an application error but we must not fail/hang/panic
because of this.

Looks ok:	gnn
No objections:	net@ (silence)
MFC after:	8 weeks

1 files changed, 6 insertions, 0 deletions

diff --git a/sys/net/route.c b/sys/net/route.c
index 94d6c24..ebfc640 100644
--- a/sys/net/route.c
+++ b/sys/net/route.c
@@ -499,6 +499,9 @@ rtrequest(int req,
 {
 	struct rt_addrinfo info;
 
+	if (dst->sa_len == 0)
+		return(EINVAL);
+
 	bzero((caddr_t)&info, sizeof(info));
 	info.rti_flags = flags;
 	info.rti_info[RTAX_DST] = dst;
@@ -1137,6 +1140,9 @@ rtinit(struct ifaddr *ifa, int cmd, int flags)
 		dst = ifa->ifa_addr;
 		netmask = ifa->ifa_netmask;
 	}
+	if (dst->sa_len == 0)
+		return(EINVAL);
+
 	/*
 	 * If it's a delete, check that if it exists, it's on the correct
 	 * interface or we might scrub a route to another ifa which would