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
This commit is contained in:
Bjoern A. Zeeb 2006-05-04 18:33:37 +00:00
parent ee40c7aa76
commit ac4a76ebc9

View File

@ -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