Hello KJ Jung,
neither of the mails you sent contain bugs.
The kernel code is sound and the vulnerabilities you reported don't seem
to exist.
In your first mail (popo:: linux kernel vulns of it),
you point out a flaw in bond_do_ioctl() and bond_set_dev_addr().
// [4]:: x90: Trigger point: slave_dev->dev_addr,
slave_dev->addr_len two variables controlled by user in memcpy
API.
622 memcpy(bond_dev->dev_addr, slave_dev->dev_addr,
slave_dev->addr_len);
It is impossible to set slave_dev->dev_addr to arbitrary values userspace.
The value will be chosen from a handful of fixed hardware address lengths.
None will exceed the length of the buffer that bond_dev->dev_addr points to,
which is always 32 (include/linux/netdevice.h MAX_ADDR_LEN).
In your second email, you report a vulnerability in tun_chr_ioctl()
__tun_chr_ioctl function of ~/drivers/net/tun.c has a stack buffer
overflow vulnerability. it get's arg, ifreq_len, and copy the arg(argp)
to ifr(ifreq struct) and this steps are no bounds-checking.
...
--
3352static long tun_chr_ioctl(struct file *file,
3353 unsigned int cmd, unsigned long arg)
3354{
3355 return __tun_chr_ioctl(file, cmd, arg, sizeof (struct ifreq));
3356}
As you can clearly see, ifreq_len is set to the actual size of struct
ifreq here.
// x90:: vulnerable point::
3044 if (copy_from_user(&ifr, argp, ifreq_len)) // bug.
Which means that this piece of code is not exploitable.
There is no way to set ifreq_len from userspace.
Please refrain from sending invalid bug reports.
Regards,
RaziREKT
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
