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:
parent
ee40c7aa76
commit
ac4a76ebc9
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user