Messages in this thread |  | | From | "Sam Varshavchik" <> | Subject | Re: two probable security holes | Date | Tue, 25 Sep 2001 01:02:35 GMT |
| |
David S. Miller writes:
> From: Ken Ashcraft <kash@stanford.edu> > Date: Tue, 18 Sep 2001 14:29:57 -0700 (PDT) > > Watch ifr.ifr_name. > > Hi Ken, I believe there is some bug in your new checker algorithms for > this case. > > struct ifreq ifr; > int err; > Start---> > if (copy_from_user(&ifr, (void *)arg, sizeof(ifr))) > return -EFAULT; > ifr.ifr_name[IFNAMSIZ-1] = '\0'; > > ifreq copied safely to kernel space, ifr.ifr_name[] is inside the > struct and NOT a user pointer. > > err = tun_set_iff(file, &ifr); > > Pass address of kernel ifreq. > > if (*ifr->ifr_name) > name = ifr->ifr_name; > > if ((err = dev_alloc_name(&tun->dev, name)) < 0) > goto failed; > > Perfectly fine still, name always points to kernel memory. > > int dev_alloc_name(struct net_device *dev, const char *name) > { > ... > > for (i = 0; i < 100; i++) { > Error---> > sprintf(buf,name,i); > > Still fine, as stated "name" is pointing to kernel memory.
Ummm... Is it possible for name to be, oh, something like
"foo%s%s%s%s%s"?
In that case, what would that sprintf do?
> Perhaps your code is being confused by "ifreq->if_name" being > an array.
-- Sam
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |